محاكاة API والمحاكاة الافتراضية للخدمات

لماذا يهم

كثيراً ما توقف الاعتماديات الحقيقية الاختبار: خدمة فريق آخر لم تُبنَ بعد، أو بيئة Sandbox لدى طرف ثالث متوقفة، أو استدعاءات تكلّف مالاً أو تصطدم بحدّ معدل الطلبات، أو بيانات مشتركة تتغير بين تشغيل وآخر. والاختبارات التي تعتمد عليها تفشل لأسباب لا علاقة لها بالشيفرة قيد الاختبار.

والأهم أن البدائل تجعل مسارات الخطأ قابلة للاختبار. فمزوّد الدفع الحقيقي لن يعيد 503 أو 429 أو ردّاً بعد ⁦15⁩ ثانية متى طلبت ذلك، مع أن هذه هي اللحظات التي يُخصم فيها المبلغ من العميل مرتين أو تضيع فيها الطلبات. والثمن أن البديل لا يصلح إلا بقدر شبهه بالواجهة الحقيقية؛ فالبديل الخاطئ يعطي اختبارات ناجحة وإخفاقات في بيئة الإنتاج.

Stub وMock وFake حين تكون الاعتمادية واجهة API

يرسل النظام قيد الاختبار طلبات HTTP حقيقية، ويجيب عنها شيء غير الخدمة الحقيقية. ولا يتغير إلا الإعداد: فعنوان URL الأساسي للاعتمادية، مثل PAYMENT_API_URL، يشير إلى البديل في CI وإلى المزوّد الحقيقي في Staging. وفي العمل اليومي على الواجهات تُستخدم كلمة «Mock» بتساهل، و«خادم Mock» يُضبط في الغالب ليعمل كبديل Stub. وحين يهمّ الفرق، اسأل ماذا يفعل البديل فعلاً:

• Stub: يعيد استجابة جاهزة لكل طلب يطابقه، مثل GET /v1/rates/RUH ← 200 {"fee": 18}، ولا يتذكر شيئاً. ويتحقق الاختبار من نتيجة نظامك، كالرسوم المعروضة (التحقق من الحالة).
• Mock: يجيب كما يجيب Stub، لكنه مبرمج مسبقاً بتوقعات عن الطلبات التي يجب أن تصله، مثل طلب POST /v1/charges واحد بالضبط مع ترويسة Idempotency-Key. ويفشل الاختبار إذا غاب الاستدعاء أو تكرر أو اختلف (التحقق من السلوك). والاختبار الذي يقرأ سجل الطلبات بعد ذلك يستخدم البديل بوصفه Spy.
• Fake: تنفيذ مبسّط لكنه يعمل، وله حالته الخاصة، في الذاكرة عادةً: POST /v1/orders يخزّن الطلب وGET /v1/orders/{id} يعيده. وهو مفيد حين تعتمد الاستدعاءات بعضها على بعض، لكن منطقه نفسه قد يكون خاطئاً.
• المحاكاة الافتراضية للخدمات: نظام تابع محاكى داخل بيئة اختبار مشتركة، وغالباً ما يُبنى بتسجيل حركة مرور حقيقية، مع الحالة والتأخير والأعطال، وأحياناً لبروتوكولات غير HTTP. وبناؤه وصيانته أعلى تكلفة، وكثيراً ما يملكه فريق المنصة أو فريق بيئات الاختبار. وبعض الفرق تستخدم المصطلح مرادفاً لمحاكاة الواجهات البرمجية؛ والفرق هو النطاق والملكية.

جرّبها: مولّد استجابات API وهمية جرّبها: مولّد بيانات JSON وهمية

متى تستخدم المحاكاة، ومتى تستخدم الواجهة الحقيقية

قرّر لكل اعتمادية ولكل مستوى اختبار: استبدل ما لا تملكه أو لا تتحكم فيه، واستخدم الشيء الحقيقي لما يجب أن يثبته الاختبار. لا تستبدل النظام قيد الاختبار نفسه أبداً. واحتفظ بالاعتمادية الحقيقية أو ببيئة Sandbox لدى المزوّد لفحوص تكامل النظام والفحوص من طرف إلى طرف. ولا تستبدل أبداً ضابط الحماية الذي تختبره ببديل Stub: فالبديل الذي يقبل أي رمز وصول لا يثبت شيئاً عن المصادقة. ويستحق البديل جهده حين:

• لا تكون الاعتمادية موجودة بعد: بديل Stub مبني من مستند OpenAPI متفق عليه يتيح بدء الاختبار مبكراً.
• تكون الاعتمادية لطرف ثالث بطيء، أو يتقاضى أجراً عن كل استدعاء، أو يحدّ معدل الطلبات، أو ليست لديه بيئة Sandbox صالحة.
• تحتاج إلى استجابات لن تعطيها الخدمة الحقيقية عند الطلب: 429 مع Retry-After، و503، وانتهاء المهلة، وجسم ليس JSON، وقائمة فارغة.
• يجب أن تكون الاختبارات سريعة وقابلة للتكرار في CI، أياً كانت حالة البيئات المشتركة.

مثال تطبيقي: حالات تعذّر الدفع عند إتمام الشراء

بيئة Sandbox لدى مزوّد الدفع لا تعيد إلا خصماً ناجحاً أو بطاقة مرفوضة. والمتطلب R-21 ينص على: «البطاقة المرفوضة تُبقي الطلب UNPAID ويُعرض سبب الرفض. وإذا كان المزوّد مشغولاً أو غير متاح، يبقى الطلب UNPAID ويُطلب من العميل المحاولة لاحقاً. وإذا لم يصل رد خلال ⁦10⁩ ثوانٍ، يصبح الطلب PAYMENT_PENDING وتُفحص حالة الخصم لاحقاً، ولا يُخصم المبلغ مرة أخرى أبداً». وتوجّه بيئة الاختبار عنوان URL الأساسي للدفع إلى خادم Stub، مع بديل Stub لكل رمز بطاقة:

• الصفان الأولان فقط يمكن إحداثهما في بيئة Sandbox؛ ومن دون بدائل Stub كانت الصفوف الأربعة الأخرى ستظهر أول مرة على الأرجح في بيئة الإنتاج، أمام عملاء حقيقيين.
• tok_slow يحتاج إلى أكثر من Stub: فإلى جانب حالة الطلب، يتحقق الاختبار من وصول طلب خصم واحد بالضبط، حتى بعد أن يضغط العميل «ادفع» مرة ثانية، إما بتوقّع مضبوط مسبقاً في Mock وإما بقراءة سجل الطلبات بعد ذلك (Spy).
• tok_broken ليس في R-21: لقد جاء من سؤال المختبِر «ماذا لو لم يكن الجسم JSON؟»، واختار الفريق معاملته كمزوّد غير متاح.

Stub server for the payment provider (test environment only)
Request: POST /v1/charges; the stub is chosen by "token" in the body

token         Stub response                         Expected in our system
------------  ------------------------------------  ------------------------------
tok_ok        201 {"status":"captured"}             order PAID, receipt sent
tok_declined  422 {"error":"card_declined"}         order UNPAID, reason shown
tok_busy      429, Retry-After: 30                  order UNPAID, "try again later"
tok_down      503 {"error":"unavailable"}           order UNPAID, "try again later"
tok_slow      201, but only after 15 s              at 10 s: PAYMENT_PENDING and
                                                    exactly one charge request
tok_broken    200, body is an HTML error page       handled as unavailable, logged

جرّبها: محاكي رموز حالة API جرّبها: مولّد استجابات خطأ وهمية

مخاطر المحاكاة وكيف تحتويها

البديل افتراض عن نظام آخر مكتوب في صورة شيفرة اختبار. وكل خطر هو طريقة يخطئ بها هذا الافتراض:

• الانحراف (Drift): يعيد المزوّد تسمية حقل أو يغيّر صيغة أخطائه، ويظل البديل يجيب بالطريقة القديمة، فيقع الإخفاق في بيئة الإنتاج بينما تبقى الاختبارات ناجحة. تحقّق من أجسام استجابات بدائل Stub مقابل عقد المزوّد، وشغّل اختبارات عقد ترسل الطلبات نفسها إلى بيئة Sandbox لدى المزوّد وتقارن إجاباتها بإجابات البدائل، وفق جدول منتظم كمرة في اليوم، ومع كل إصدار للمزوّد. والعقود التي يقودها المستهلك (Consumer-Driven Contracts) ويتحقق منها المزوّد تسدّ الثغرة من الجهة الأخرى.
• السلوك غير الواقعي: تجيب البدائل فوراً ولا تحدّ معدل الطلبات أبداً. أضف تأخيراً واقعياً حيث يهمّ التوقيت، واحتفظ ببضعة اختبارات مقابل الخدمة الحقيقية.
• الإفراط في المحاكاة (Over-mocking): بدائل كثيرة إلى حدّ أن الاختبار لا يختبر إلا البدائل، أو توقعات صارمة في الترويسات وترتيب الاستدعاءات إلى حدّ أن تغييرات غير ضارة تكسر الاختبارات.
• التسرّب: عنوان URL لبديل Stub يبقى في إعدادات Staging أو الإنتاج. يجب أن تذكر كل بيئة أيّ الاعتماديات حقيقية، وأن تؤكد فحوص النشر ذلك.
• البيانات المسجّلة: قد تحتوي حركة المرور المسجّلة للمحاكاة الافتراضية للخدمات على بيانات شخصية ورموز وصول. أخفِها قبل تخزينها أو مشاركتها.

جرّبها: مدقّق مخططات API جرّبها: مقارنة عقود الاستجابات

أسئلة شائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• Test Double (Martin Fowler)martinfowler.com · 2006مصطلحات Gerard Meszaros لبدائل الاختبار (Test Doubles) — dummy وfake وstub وspy وmock — كما لخّصها Martin Fowler.
• Mocks Aren't Stubs (Martin Fowler)martinfowler.com · 2007الفرق بين التحقق من الحالة والتحقق من السلوك، وبين الأسلوب الكلاسيكي وأسلوب الكائنات الوهمية (mockist) في التطوير الموجّه بالاختبار.
• Contract Test (Martin Fowler)martinfowler.com · 2011اختبارات العقود: فحوص دورية تتأكد من أن الاستدعاءات الموجّهة إلى بديل الاختبار تعيد النتائج نفسها التي تعيدها الخدمة الخارجية الحقيقية.