تكرار السؤال: …
الإجابة المختصرة
تتحقق اختبارات التعاقد من توافق واجهات الـ API بين المستهلك (Consumer) والمزود (Provider) بشكل مستقل ومنفصل دون الحاجة لتشغيل النظام الموزع بالكامل في بيئة اختبار موحدة.
الشرح
في معمارية المايكروسيرفس، تشغيل 50 خدمة معاً لاختبارات E2E بطيء جداً وغير مستقر ومكلف. بدلاً من ذلك، في Consumer-Driven Contract Testing (باستخدام أدوات مثل Pact)، يكتب المستهلك اختباراً يحدد ما يتوقعه من المزود (عقد Contract بصيغة JSON). يُرسل هذا العقد لوسيط (Pact Broker)، ثم يقوم المزود بتشغيل اختبار ضد هذا العقد للتحقق من التزامه به. إذا قام المزود بتغيير حقل حاسم يكسر المستهلك، يفشل بناء المزود فوراً قبل النشر دون أي حاجة لبيئات متصلة.
مثال بالكود
# Consumer side — what the client needs from GET /users/1
CONTRACT = {
"request": {"method": "GET", "path": "/users/1"},
"response": {"status": 200, "body": {"id": int, "fullName": str}},
}
# Provider side — verified in CI against the real API, no shared E2E environment required
def test_provider_honours_contract(client):
response = client.get(CONTRACT["request"]["path"])
assert response.status_code == CONTRACT["response"]["status"]
body = response.json()
for field, expected_type in CONTRACT["response"]["body"].items():
assert isinstance(body[field], expected_type)أخطاء شائعة
- الاعتماد على افتراضات شفهية أو توثيق يدوي قديم بين فرق الـ Frontend والـ Backend، مما يؤدي لكسر الإنتاج عند النشر المستقل.