تعرف معظم الفرق كيفية محاكاة واجهة برمجة التطبيقات (API). لكن عددًا أقل لديهم إجابة واضحة حول متى تكون هذه المحاكاة مفيدة بالفعل ومتى تضيف طبقة أخرى يجب صيانتها. المحاكاة التي تستخدمها في اللحظة المناسبة تزيل عنق الزجاجة الحقيقي. أما المحاكاة التي تنشئها من باب العادة فتصبح شيئًا آخر ينحرف عن الواقع ويكذب عليك بهدوء.
تتخطى هذه المقالة كيفية القيام بذلك وتركز على متى يتم ذلك. كل قسم يمثل موقفًا ملموسًا حيث تثبت المحاكاة قيمتها: البناء مقابل واجهة خلفية غير مكتملة، اختبار مسارات الأخطاء، الحلول محل خدمة طرف ثالث غير مستقرة، تشغيل العروض التوضيحية، وتثبيت التكامل المستمر (CI). اقرأها كمساعدة في اتخاذ القرار، وليس كدليل تعليمي.
التطوير المتوازي للواجهة الأمامية والخلفية
هذه هي الحالة الكلاسيكية. يحتاج فريق الواجهة الأمامية إلى نقطة نهاية لم يقم فريق الواجهة الخلفية ببنائها بعد. بدون محاكاة، تنتظر الواجهة الأمامية أو تقوم بالبرمجة بناءً على تخمينات تتعطل عند أول اتصال بالخدمة الحقيقية.
المحاكاة تكسر هذا الاعتماد. يتفق الفريقان على العقد أولاً، عادةً كوثيقة OpenAPI. تبني الواجهة الأمامية مقابل محاكاة تم إنشاؤها من هذا العقد بينما تنفذ الواجهة الخلفية الشيء الحقيقي. عندما يتم شحن الواجهة الخلفية، تبدل الواجهة الأمامية عنوان URL الأساسي، وإذا التزم كلا الجانبين بالعقد، فلا يتغير شيء آخر.
الاتفاق هو الجزء الأساسي. المحاكاة التي يبتكرها فريق الواجهة الأمامية وحده لا تقوم إلا بتشفير افتراضات فريق واحد. المحاكاة المشتقة من مواصفات مشتركة تبقي كلا الفريقين متوافقين، وهو نفس المبدأ وراء اختبار عقد API. استخدم المحاكاة لفك حظر العمل المتوازي، ولكن فقط بناءً على عقد وافق عليه كلا الطرفين.
يتضاعف العائد عبر المشروع. فريق الواجهة الأمامية الذي لا يتوقف أبدًا بسبب الواجهة الخلفية يشحن الميزات وفقًا لجدوله الخاص. فريق الواجهة الخلفية الذي لا يتم إزعاجه بسبب نقاط نهاية نصف مبنية يبقى مركزًا. يحصل المصممون ومديرو المنتجات على إصدار قابل للنقر للتفاعل معه قبل أسابيع. لا شيء من ذلك يتطلب وجود الخدمة الحقيقية بعد. التكلفة الجارية الوحيدة هي إبقاء المحاكاة متوافقة مع العقد مع تطوره، وهو أمر رخيص عندما يتم إنشاء المحاكاة من المواصفات بدلاً من كتابتها يدويًا.
اختبار مسارات الأخطاء التي لا يمكنك تشغيلها عند الطلب
تعيد واجهة برمجة التطبيقات (API) السليمة رمز 200. هذه هي المشكلة. يجب أن يتعامل رمز العميل الخاص بك أيضًا مع 429، 500، 503، والهيئات ذات التنسيق الخاطئ، والمهلات، ولن ينتج الخادم العامل هذه الأخطاء عندما يطلبها اختبارك.
تنتج المحاكاة هذه الأخطاء عند الطلب. يمكنك تكوينها لإعادة 500 لطلب واحد، و 429 مع رأس Retry-After لطلب آخر، وهيئة تصل بعد تأخير متعمد لطلب ثالث. ثم تتأكد من أن منطق إعادة المحاولة، والعودة التدريجية (backoff)، ومعالجة المهلات لديك تعمل جميعها بشكل صحيح.
| الفشل في الاختبار | إعداد المحاكاة | ماذا يثبت |
|---|---|---|
| خطأ في الخادم | إعادة 500 |
يعيد العميل المحاولة، ثم يتراجع بأمان |
| تحديد المعدل | 429 مع Retry-After |
ينتظر العميل الفترة الزمنية الصحيحة |
| شبكة بطيئة | تأخير الاستجابة 5 ثوانٍ | ينتهي وقت العميل بشكل نظيف |
| حمولة سيئة | إعادة JSON معطوب | يفشل المحلل اللغوي دون تعطل |
هذه هي حالة الاستخدام التي تتجاهلها الفرق غالبًا وتندم عليها أكثر من غيرها. التعامل مع الأخطاء الذي لم يتم اختباره مطلقًا هو تعامل مع الأخطاء لا تملكه. قم بإقران المحاكاة بتأكيدات API شاملة بحيث يتم التحقق من كل مسار فشل، وليس افتراضه.
هناك فئة ثانية من الأخطاء تستحق المحاكاة: الاستجابات التي تكون HTTP صالحة ولكنها خاطئة بالنسبة لمجالك. رمز 200 بسعر سلبي، طلب بحالة ليست في تعدادك، قائمة صفحات مؤشرها next لا يشير إلى أي مكان. الخادم الحقيقي، إذا كان صحيحًا، لا يرسل هذه الأخطاء أبدًا. يمكن للمحاكاة أن تفعل ذلك، وتزويد عميلك ببيانات مشوهة عمدًا ولكنها جيدة التنسيق هو كيف تجد الافتراضات التي يفترضها رمز التحليل الخاص بك بصمت.
الحلول محل واجهة برمجة تطبيقات طرف ثالث
استدعاء معالج دفع حقيقي، أو خدمة خرائط، أو واجهة برمجة تطبيقات للشحن داخل اختباراتك أمر بطيء، وأحيانًا يكلف المال لكل مكالمة، ويعتمد على خدمة لا تتحكم فيها. إذا كان صندوق الرمل الخاص بهم معطلاً، فإن مجموعتك معطلة.
قم بمحاكاة الطرف الثالث. تسجل استجاباته الحقيقية مرة واحدة، أو تبني محاكاة من مخططها المنشور، ثم تقوم بتشغيل اختباراتك مقابل المحاكاة. تصبح الاختبارات سريعة ومجانية وحتمية. كما أنها تستمر في العمل عندما يكون لدى البائع انقطاع.
هناك تكلفة صيانة. يمكن للطرف الثالث تغيير واجهة برمجة التطبيقات الخاصة به دون إخبارك، ولن تعرف محاكاتك بذلك. الحل هو مهمة مجدولة صغيرة تستدعي الخدمة الحقيقية وتؤكد أن الاستجابة لا تزال تتطابق مع شكل محاكاتك. يعد فحص العقد هذا هو المكان الوحيد الذي تلمس فيه الطرف الثالث الحي، ويلتقط الانجراف قبل أن يلاحظه المستخدمون. من المفيد أيضًا الاشتراك في سجل التغييرات الخاص بالبائع، بحيث يصلك التغيير المخطط قبل أن يصلك اختبار العقد الفاشل.
تشغيل العروض التوضيحية والنماذج الأولية
العرض التوضيحي الذي يستدعي الخدمات الحية أمام العميل هو مقامرة. استعلام بطيء، أو مجموعة نتائج فارغة، أو انقطاع غير محظوظ يحول عرضًا مصقولًا إلى اعتذار.
المحاكاة تجعل العرض التوضيحي حتمياً. تقوم ببرمجة البيانات التي يحتاجها العرض التوضيحي بالضبط: الطلب الذي يتم شحنه في الوقت المحدد، لوحة المعلومات ذات الأرقام الصحية، البحث الذي يعيد نتائج نظيفة. وينطبق الشيء نفسه على النماذج الأولية. يمكنك التحقق من صحة تدفق واجهة المستخدم أو طرح ميزة قبل وقت طويل من وجود أي واجهة خلفية، لأن المحاكاة توفر كل استجابة يتوقعها النموذج الأولي.
النقطة هنا ليست الاختبار، بل التحكم. أنت تقرر ما يراه الجمهور، ولا يمكن لأي شيء خارجي أن يفسده. بالنسبة للعمل في المراحل المبكرة، غالبًا ما تكون المحاكاة أسرع طريقة لعرض شيء قابل للنقر أمام الأشخاص. تتم تغطية الأدوات التي تقارن عبر الفئة في هذا المقال حول أدوات محاكاة API عبر الإنترنت.
يعمل نموذج المحاكاة الأولي أيضًا كوثيقة تصميم. عندما تُعيد المحاكاة الأشكال الدقيقة التي ستخدمها واجهة برمجة التطبيقات النهائية، فإن رمز الواجهة الأمامية الذي تكتبه مقابلها هو رمز حقيقي، وليس مجرد سقالة يمكن التخلص منها. إذا التزمت الواجهة الخلفية لاحقًا بنفس العقد، يصبح النموذج الأولي المنتج بتغيير بسيط في عنوان URL الأساسي فقط. هذا هو الفرق بين المحاكاة المستخدمة كدعامة والمحاكاة المستخدمة كنقطة انطلاق.
الحفاظ على سرعة واستقرار التكامل المستمر (CI)
مجموعة الاختبار التي تستدعي خدمات خارجية في التكامل المستمر (CI) ترث كل المشاكل التي تواجهها تلك الخدمات. تقلبات الشبكة، حدود المعدل، بيانات المرحلة المشتركة التي غيرها بناء آخر للتو: كل ذلك يتحول إلى فشل متقطع لا علاقة له بالرمز قيد المراجعة.
الاختبارات المتقلبة تدرب الناس على تجاهل الفشل، مما يقوض الغرض من CI. محاكاة التبعيات الخارجية تجعل المجموعة محكمة. تبدأ كل عملية تشغيل من نفس الحالة المعروفة، وتنتهي بشكل أسرع لأنه لا توجد رحلة ذهاب وعودة عبر الشبكة، وتفشل فقط عندما يكون الكود مكسورًا بالفعل.
ابق على استثناء واحد. قم بتشغيل طبقة رفيعة من اختبارات العقد مقابل واجهة برمجة التطبيقات الحقيقية في جدول زمني، منفصلة عن مجموعة الاختبارات لكل عملية التزام (commit). تؤكد هذه الاختبارات أن المحاكاة لا تزال متطابقة مع الإنتاج. تبقى مجموعة الاختبارات لكل التزام سريعة ومحاكاة؛ وتلتقط المهمة المجدولة الانحراف. هذا الانقسام أساسي لخط أنابيب اختبار CI/CD صحي.
إن كسب السرعة ليس ميزة ثانوية. فمجموعة الاختبار التي تنخفض من اثنتي عشرة دقيقة إلى تسعين ثانية تغير طريقة عمل الفريق. يقوم المطورون بتشغيلها قبل كل عملية دفع بدلاً من الأمل. يرى المراجعون النتائج في الوقت الذي يستغرقه قراءة الفرق. إن مجموعة الاختبار السريعة والمحكمة هي التي يثق بها الناس بالفعل، والثقة هي العائد الكامل على الاستثمار في الاختبارات الآلية.
متى لا يجب المحاكاة
للمحاكاة وضع فشل: محاكاة لم تعد تتطابق مع الواقع. تبقى الاختبارات خضراء بينما يتعطل الإنتاج، لأنها تتحقق من خيال.
لا تقم بالمحاكاة عندما يكون الشيء الذي يتم اختباره هو التكامل نفسه. توجد اختبارات العقد والفحوصات الشاملة للتحقق من الحدود الحقيقية، لذا فإن محاكاتها تزيل سبب وجودها. لا تقم بمحاكاة تبعية لا تتحقق منها مطلقًا مقابل الشيء الحقيقي، لأن المحاكاة غير المتحقق منها ستنحرف. ولا تلجأ إلى المحاكاة عندما تكون الخدمة الحقيقية سريعة ومجانية وموثوقة في بيئة الاختبار الخاصة بك؛ فالمحاكاة ستكون مجرد عبء إضافي.
القاعدة الأساسية: استخدم المحاكاة من أجل السرعة والعزل والتحكم، واحتفظ بمجموعة صغيرة وصادقة من الاختبارات التي تلامس الواقع لتأكيد أن المحاكاة لا تزال صحيحة. إذا كنت تريد أن تعيش المحاكاة وفحص العقد في مكان واحد، فإن Apidog يولد محاكاة من تصميم API الخاص بك ويُشغل الاختبارات ضد كل من المحاكاة ونقطة النهاية الحية. لإعداد ذلك، حمل Apidog وابدأ من مواصفاتك الحالية. وللأسس المفاهيمية، انظر ما هي واجهة برمجة التطبيقات الوهمية بالفعل.
الأسئلة المتداولة
متى يجب أن أقوم بمحاكاة واجهة برمجة تطبيقات بدلاً من استدعاء الواجهة الحقيقية؟
قم بالمحاكاة عندما تحتاج إلى السرعة أو العزل أو التحكم: التطوير المتوازي مقابل واجهة خلفية غير مكتملة، واختبار مسارات الأخطاء التي لن ينتجها خادم حقيقي، والحلول محل خدمة طرف ثالث بطيئة أو مدفوعة، وتشغيل العروض التوضيحية، والحفاظ على استقرار CI. استدعِ واجهة برمجة التطبيقات الحقيقية لاختبارات العقد والاختبارات الشاملة.
هل تحل المحاكاة محل اختبار التكامل؟
لا. المحاكاة مخصصة لاختبارات الوحدات والمكونات حيث تقوم بفحص الكود الخاص بك. يجب أن تصل اختبارات التكامل والعقود إلى الحدود الحقيقية، حيث أن مهمتها هي تأكيد أن الخدمة الفعلية تتطابق مع العقد. محاكاة هذه الاختبارات تزيل الغرض منها.
كيف أحافظ على محاكاة من الانحراف عن الواقع؟
قم بإنشاء المحاكاة من مخطط مشترك، ويفضل أن يكون OpenAPI، بحيث يؤدي تغيير العقد إلى تحديثها. ثم قم بتشغيل اختبارات العقد المجدولة مقابل واجهة برمجة التطبيقات الحقيقية للتأكد من أن الاستجابة الحية لا تزال تتطابق مع هذا المخطط. يتم اكتشاف الانحراف قبل أن يصل إلى المستخدمين.
هل يمكنني محاكاة واجهة برمجة تطبيقات لطرف ثالث لا أتحكم فيه؟
نعم، وهي إحدى أقوى حالات الاستخدام. قم بتسجيل استجابات الطرف الثالث الحقيقية أو بناء نماذج محاكاة من مخططها المنشور، ثم اختبر مقابل المحاكاة للسرعة والموثوقية. أضف فحصًا مجدولًا مقابل الخدمة الحية لتلاحظ عندما يغير البائع واجهة برمجة التطبيقات الخاصة به.
هل المحاكاة مفيدة للعروض التوضيحية والنماذج الأولية؟
نعم جداً. تجعل المحاكاة العرض التوضيحي حتمياً عن طريق برمجة البيانات التي تريد أن يراها الجمهور بالضبط، دون أي خطر من انقطاع مباشر أو بيانات غير محظوظة. أما بالنسبة للنماذج الأولية، تتيح لك المحاكاة بناء تدفق لواجهة المستخدم والتحقق منه قبل وجود أي واجهة خلفية.