أفضل بديل لـ باكت

Pact هي الأداة المرجعية لاختبار العقود المدفوع بالمستهلك. يقوم المستهلكون بكتابة اختبارات الوحدات التي تنشئ عقدًا، ويعيد الموفرون تشغيل هذا العقد مقابل التعليمات البرمجية الحقيقية الخاصة بهم، ويقوم Pact Broker بتخزين النتائج، ويخبر can-i-deploy مسار عملك (pipeline) ما إذا كان الإصدار آمنًا للنشر. عندما تعمل هذه الحلقة، فإنها تلتقط حالات توقف التكامل التي لا يمكن لاختبارات الوحدات المعزولة اكتشافها أبدًا. المشكلة هي الحلقة نفسها: DSLs اختبار خاصة بكل لغة في كل فريق مستهلك، حالات موفر (provider states) يجب برمجتها وصيانتها، وسيط (broker) لاستضافته وتحديد إصداراته، وعمليات بناء تحقق الموفر (provider verification builds) التي تفشل لأسباب لا يمكن لأحد إعادة إنتاجها محليًا. تعتمد العديد من الفرق Pact لتكامل واحد غير مستقر وينتهي بها الأمر إلى توظيف فريق صغير لمنصة اختبار العقود.

إليك الإجابة المباشرة، مع توضيح نطاقها مقدمًا: Apidog هو أفضل بديل لـ Pact للفرق التي تكمن مشكلتها الحقيقية في تباين المخطط (schema drift) بين المنتج والمستهلك، وهو ما ينطبق على معظم الفرق. إنه يستبدل عملية إنشاء العقود (pact-generation) بمواصفة OpenAPI واحدة كمصدر للحقيقة، ويتحقق من صحة كل استجابة مقابل هذا المخطط في كل دورة اختبار، ويقدم نماذج ذكية (smart mocks) من المواصفة بحيث يبني المستهلكون مقابل العقد قبل أن ينشر الموفر، ويشغل كل ذلك في CI من خلال Apidog CLI. ما لا يفعله هو تكرار سير عمل وسيط Pact المدفوع بالمستهلك: لا يوجد ملف عقد (pact file)، ولا مصفوفة (matrix)، ولا can-i-deploy. إذا كنت بحاجة إلى هذه الآلية الدقيقة عبر العديد من الفرق التي تنشر بشكل مستقل، فإن Pact يحتفظ بمكانته، ويذكر هذا المقال ذلك أدناه.

ما يفعله Pact بالفعل، ويتقنه

تصف وثائق Pact الأداة بأنها أداة تعتمد على التعليمات البرمجية أولاً (code-first) لاختبار تكاملات HTTP والرسائل. النموذج مدفوع بالمستهلك: يتم تشغيل اختبارات المستهلك مقابل موفر Pact الوهمي (mock provider) وتسجيل أزواج الطلب/الاستجابة المحددة في ملف عقد (pact file). يتم تسجيل الحقول التي يستخدمها المستهلك فقط، لذا يظل الموفرون أحرارًا في تغيير أي شيء لا يعتمد عليه أحد. ثم يتحقق الموفر من العقد عن طريق إعادة تشغيل تلك الطلبات مقابل قاعدة التعليمات البرمجية الحقيقية الخاصة به، مع قيام حالات الموفر (provider states) بإعداد البيانات التي يحتاجها كل تفاعل.

يحول Pact Broker تلك القطع الأثرية إلى منطق نشر. يهبط كل زوج من إصدارات المستهلك والموفر المتحقق منه في مصفوفة، ويتحقق can-i-deploy مما إذا كان الإصدار الذي أنت على وشك نشره قد تم التحقق منه بنجاح مقابل كل شيء يعمل بالفعل في البيئة المستهدفة. رمز الخروج 0 يعني النشر، و 1 يعني عدم النشر.

النظام البيئي واسع: توجد تطبيقات رسمية بأكثر من 10 لغات، بما في ذلك JVM، JavaScript، Go، .NET، Python، Ruby، Rust، PHP، و Swift، معظمها يشارك جوهر Rust الأصلي. وبما أن استضافة وسيط ذاتيًا عمل حقيقي، تبيع SmartBear PactFlow، وهو وسيط مُدار يقدم طبقة Starter مجانية (لتكاملين)، وطبقة Team بسعر 127 دولارًا شهريًا لـ 50 تكاملًا، ونسخة Enterprise بأسعار مخصصة مع خيارات SSO والنشر المحلي.

حيث تتراكم التعقيدات

المشكلة هي تكلفة "تشغيل الحلقة" في الواقع العملي.

• كل فريق مستهلك يكتب تعليمات DSL البرمجية. يتم إنشاء العقود (Pacts) من تعليمات الاختبار البرمجية، لذا يتعلم كل فريق مستهلك لغة DSL الخاصة بـ Pact للغته، وتتعلم المؤسسة متعددة اللغات عدة لغات. قواعد المطابقة وإعداد النماذج الوهمية (mock setup) هي تعليمات برمجية تكتبها وتراجعها وتعيد هيكلتها باستمرار.
• حالات الموفر (Provider states) هي مجموعة اختبارات مخفية. قد يتطلب كل تفاعل حالة ("المستخدم 42 موجود بفاتورة غير مدفوعة")، ويجب على فريق الموفر تنفيذ معالج (handler) يقوم ببنائها. مع تزايد عدد المستهلكين، يحافظ الموفر على كتالوج من معالجات الحالات لأشكال البيانات التي لا يتحكم فيها.
• الوسيط (Broker) هو بنية تحتية. إذا كان مُستضافًا ذاتيًا، فإنه يحتاج إلى قاعدة بيانات، وتحديثات، ومصادقة (auth)، و webhooks في كل نظام CI. إذا كان مُدارًا، فهو بائع آخر. في كلتا الحالتين، يجب تعليم انضباط إدارة الإصدارات (أسماء الفروع، سجلات البيئة، العقود المعلقة) لكل فريق يتعامل معه.
• فشل تحقق الموفر (Provider verification flakes). يعيد التحقق تشغيل الطلبات المسجلة من قبل المستهلك مقابل مثيل موفر حي، مما يستدعي وقت تشغيل الموفر بالكامل: بذور قاعدة البيانات (database seeds)، كعبات المصادقة (auth stubs)، وظائف الخلفية (background jobs). عندما يصبح البناء أحمر، يكون الاختبار الفاشل قد كتبه فريق آخر ويمنع نشرهم من خلال can-i-deploy. جلسة تصحيح الأخطاء عبر الفرق هذه هي عندما تبدأ الفرق في تخطي هذا التحقق بهدوء.

PactFlow نفسه يقر بهذا العبء. اختبار العقود ثنائي الاتجاه (bi-directional contract testing) في PactFlow يلغي خطوة إعادة التشغيل: ينشر الموفر مستند OpenAPI كعقده، وينشر المستهلكون عقودًا مشتقة من النماذج الوهمية، ويقارن PactFlow بين الاثنين بشكل ثابت. هذا اعتراف من البائع بأن مقارنة المخططات (schemas) تكفي للعديد من التكاملات. وإذا كانت المواصفة هي العقد، فماذا تمنحك بقية الآلية؟ لقد استعرضنا نفس المنطق في اختبار العقود ثنائي الاتجاه.

الإجابة: Apidog

Apidog هي منصة تطوير واجهات برمجة التطبيقات (API) يستخدمها أكثر من 500,000 مطور. تضع مواصفة OpenAPI واحدة في المركز وتولد كل شيء آخر منها: الوثائق، خوادم النماذج الوهمية (mock servers)، التحقق من صحة الطلبات، والاختبارات الآلية. كبديل لـ Pact، الفكرة هي نظرية مختلفة للعقود، تلك التي طرحناها في اختبار العقود لواجهة برمجة التطبيقات (API): اجعل المواصفة هي العقد، ثم طبقها ميكانيكيًا في كل مكان.

1. عقد واحد، صفر لغات DSL. المواصفة هي الاتفاق بين المنتج والمستهلك. لا يكتب أحد تعليمات برمجية لإنشاء العقود بخمس لغات؛ تقرأ الفرق وثيقة واحدة وتعدلها، بصريًا أو كتعليمات برمجية.
2. التحقق من صحة المخطط (Schema validation) في كل دورة تشغيل. كل طلب ترسله في Apidog، وكل سيناريو اختبار في CI، يتحقق من صحة الاستجابة مقابل المواصفة تلقائيًا. أي حقل تمت إعادة تسميته، أو تغيير في النوع، أو خاصية محذوفة، يتسبب في فشل التشغيل دون أن يكتب أي شخص تأكيدًا. هذا هو اكتشاف التباين (drift detection) الذي اشترت معظم الفرق Pact لأجله.
3. يطور المستهلكون مقابل العقد من اليوم الأول. يقدم خادم النماذج الوهمية الذكي (smart mock server) استجابات واقعية مشتقة من المخطط فور تعريف نقطة نهاية. لا توجد حالات موفر (provider states) لبرمجتها؛ يتم إنشاء النموذج الوهمي، وليس بناؤه يدويًا.
4. تطبيق CI بدون وسيط. يقوم apidog run بتنفيذ سيناريوهات الاختبار في أي مسار عمل. يؤدي بناء موفر (provider build) يكسر المواصفة إلى فشل CI الخاص به قبل النشر: نفس نتيجة "لا تنشر تغييرًا تسبب في كسر"، يتم فرضها من المصدر بدلاً من المصفوفة.

كيف يبدو التحول، خطوة بخطوة

العقد نفسه

في Pact، العقد هو ملف JSON تم إنشاؤه من تفاعلات أمثلة؛ يصف ما لاحظه مستهلك واحد. في Apidog، العقد هو مواصفة OpenAPI: الأنواع، الحقول المطلوبة، التعدادات (enums)، وأشكال الأخطاء لكل نقطة نهاية، تملك في مكان واحد مع تحديد الإصدارات المستندة إلى الفروع. المقايضة صادقة: يخبر جزء Pact الخاص بكل مستهلك الموفر بالضبط أي الحقول آمنة للتغيير، ولا تحمل المواصفة المشتركة إشارة الاستخدام هذه. ما توفره المواصفة بدلاً من ذلك هو قطعة أثرية واحدة تتفق عليها جميع الوثائق والنماذج الوهمية والاختبارات والعملاء؛ المزيد حول هذا الإطار في ما هو عقد واجهة برمجة التطبيقات (API contract).

التحقق من جانب الموفر

يعيد Pact تشغيل تفاعلات المستهلك مقابل الموفر الحي. ما يعادله في Apidog هو تشغيل سيناريوهات الاختبار مقابل التنفيذ الحقيقي مع تشغيل التحقق من صحة المخطط (schema validation)، في CI عبر واجهة سطر الأوامر (CLI). لا يزال يتم التحقق من الموفر مقابل العقد، دون الحاجة إلى كتالوج من الحالات التي أنشأها المستهلك.

التطوير من جانب المستهلك

يوفر Pact لكل مستهلك موفرًا وهميًا (mock provider) داخل اختبارات وحدته. يوفر Apidog لكل مستهلك عنوان URL وهميًا (mock URL) قيد التشغيل مشتقًا من المواصفة، قابل للمشاركة عبر الفرق، مع توقعات مخصصة حيث تحتاج إلى بيانات محددة. تبدأ فرق الواجهة الأمامية والفرق التابعة قبل أن يكون لدى الموفر سطر واحد من التنفيذ؛ انظر اختبار العقود وخوادم النماذج الوهمية لمقارنة النماذج الوهمية الموجهة بالمواصفات (spec-driven mocks) مع تلك المبنية يدويًا.

حظر النشر

هذه هي أقوى ورقة لـ Pact ولا ينسخها Apidog. لا توجد مصفوفة عبر الخدمات ولا can-i-deploy. بدلاً من ذلك، يتحقق Apidog من العقد: يؤدي تغيير الموفر الذي ينتهك المواصفة إلى فشل مسار عمل الموفر الخاص به، وتغيير المواصفة هو حدث صريح ومراجع يعيد توليد النماذج الوهمية والوثائق لكل مستهلك في وقت واحد. حيث يتم نشر الخدمات من خلال عدد قليل من مسارات العمل المنسقة، فإن الحظر على مستوى العقد هو الحالة بنسبة 80%. بالنسبة لعشرات الفرق التي تنشر بشكل مستقل في أوقات غير معروفة، لا يزال الحظر على مستوى المصفوفة (matrix-level gating) ضروريًا.

Pact و PactFlow مقابل Apidog في لمحة

حساب التكلفة والملاءمة، بصدق

مكتبات Pact مفتوحة المصدر ومجانية للأبد. ما تدفعه هو مقابل التنسيق: استضافة الوسيط (broker hosting) أو PactFlow (تكلفة فريق العمل 127 دولارًا شهريًا، حوالي 1,385 دولارًا فاتورة سنويًا)، بالإضافة إلى وقت الهندسة الذي تستهلكه اختبارات DSL، ومعالجات الحالات، وتصحيح أخطاء التحقق عبر الفرق. ذلك الوقت هو الفاتورة الحقيقية، ويتناسب مع عدد التكاملات.

تغطي خطة Apidog المجانية 4 مستخدمين مع محرر المواصفات، واستخدام غير محدود لخادم النماذج الوهمية، وسيناريوهات الاختبار، والتحقق من صحة المخطط، وتشغيل CLI؛ وتبدأ الخطط المدفوعة من 9 دولارات لكل مستخدم شهريًا. لذا فالمقارنة ليست رسوم تراخيص. إنها تتعلق بما إذا كنت تفضل صيانة آليات اختبار العقود أو اعتماد منصة حيث يتماشى عمل العقود مع عميل API الذي كنت ترغب فيه على أي حال (هل تقوم بدمج الأدوات؟ ابدأ من أفضل بديل لـ Postman). يمكن للفرق التي تختار مكدسًا يعتمد على المواصفات أولاً من البداية أن ترى كيف تتناسب الأجزاء في مجموعة أدوات التطوير القائمة على العقد أولاً.

الهجرة من Pact

لا تقوم بتحويل ملفات العقود (pact files)؛ بل ترتقي بالمواصفة لتكون العقد.

1. احصل على مواصفة OpenAPI حقيقية. إذا كان لديك واحدة، قم باستيرادها إلى Apidog؛ ستصبح وثائقًا حية ونماذج وهمية وقواعد تحقق على الفور. إذا لم يكن لديك، فقم بإنشاء واحدة من تعليقات التعليمات البرمجية، باستخدام ملفات العقود (pact files) كقائمة تحقق لنقاط النهاية التي يستخدمها المستهلكون بالفعل.
2. قم بتشغيل التحقق من صحة المخطط (schema validation) في CI. أنشئ سيناريوهات اختبار لنقاط نهاية الموفر وقم بتشغيلها باستخدام CLI في كل بناء للموفر. هذا يحل محل تحقق الموفر.
3. وجه المستهلكين إلى النموذج الوهمي الذكي. استبدل إعدادات نماذج Pact الوهمية لكل مستهلك بعنوان URL للنموذج الوهمي المستضاف. احذف كود DSL مع تحول كل مستهلك.
4. حظر تغييرات المواصفات، وليس عمليات النشر. اجعل تعديلات المواصفات تغييرات مراجعة على فرع، بحيث تصبح التعديلات التي تسبب كسرًا اختلافات مرئية قبل أن تصبح حوادث.
5. أوقف الوسيط (broker) أخيرًا. احتفظ بـ can-i-deploy في أي تكامل حيث يمثل توقيت النشر المستقل خطرًا قائمًا؛ أسقطه حيث كان مجرد إجراء روتيني.

متى لا يزال Pact منطقيًا

إذا كانت العديد من الفرق تنشر الخدمات بشكل مستقل وفقًا لجداولها الخاصة، وكنت بحاجة إلى إجابة قابلة للتحقق آليًا على سؤال "هل يمكن للإصدار X الدخول إلى مرحلة الإنتاج الآن بالنظر إلى كل شيء آخر يعمل هناك"، فإن مصفوفة الوسيط (broker matrix) الخاصة بـ Pact وcan-i-deploy مصممة خصيصًا لذلك، ولا يكررها Apidog. اختبار عقود قائمة الرسائل (Message-queue contract testing) هو أيضًا مجال Pact. الوضع ثنائي الاتجاه في PactFlow هو الخطوة الوسطى إذا كنت ترغب في التخلص من إجراءات إعادة التشغيل دون مغادرة النظام البيئي؛ فهو يشارك فرضية Apidog بأن المواصفة يمكن أن تحمل العقد. ولكن إذا كانت مشكلتك هي تباين المخطط (drift)، والنماذج الوهمية (mocks)، وفحوصات CI بدلاً من ترتيب النشر عبر الفرق، فأنت تدفع الثمن الكامل لـ Pact مقابل جزء صغير من فائدته.

الأسئلة الشائعة

هل Apidog أداة لاختبار العقود مثل Pact؟

إنه يفرض العقود بطريقة مختلفة. يولد Pact عقودًا لكل مستهلك من كود الاختبار ويعيد تشغيلها مقابل الموفرين. يجعل Apidog مواصفة OpenAPI هي العقد ويتحقق من صحة كل طلب وتشغيل CI مقابلها، مما يغطي تباين المخطط (schema drift) دون الحاجة إلى سير عمل الوسيط. يتم تفصيل هذا الاختلاف في اختبار العقود لواجهة برمجة التطبيقات (API).

هل يدعم Apidog ميزة can-i-deploy أو Pact Broker؟

لا. لا يحتوي Apidog على مصفوفة تحقق (verification matrix) أو بوابة نشر عبر الخدمات. بوابته هي العقد: عمليات البناء التي تنتهك المواصفة تفشل مسار عملها الخاص. يجب على الفرق التي تحتاج إلى حظر على مستوى المصفوفة (matrix-level gating) الاحتفاظ بـ Pact لتلك التكاملات؛ الخيار الوسط هو نهج المقارنة الثابتة الذي تغطيه اختبار العقود ثنائي الاتجاه.

هل يمكن لـ Apidog استبدال نماذج المستهلك الوهمية الخاصة بـ Pact؟

نعم، لمعظم الاستخدامات. يولد خادم النماذج الوهمية الذكي (smart mock server) استجابات دقيقة للمخطط (schema-accurate) من المواصفة بدون أي إعداد، بالإضافة إلى توقعات مخصصة لحالات معينة، بحيث تقوم فرق المستهلكين بالبرمجة مقابل عنوان URL لعقد حي بدلاً من كتابة DSL لموفر وهمي. انظر اختبار العقود وأدوات النماذج الوهمية للحصول على نظرة أوسع لمشهد الأدوات.

ماذا عن اختبار Fuzzing للموفر ضد المواصفة؟

يمنح دمج اختبارات سيناريوهات Apidog مع مُختبِر الخصائص المستند إلى المواصفات تغطية سلبية أوسع من إعادة تشغيل الأمثلة. لقد قارنا الخيار الرائد في ما هو Schemathesis، وتدفع نفس المواصفة كلا الأداتين.

كم تبلغ تكلفة PactFlow مقارنة بـ Apidog؟

طبقة Starter في PactFlow مجانية لتكاملين؛ تبلغ تكلفة طبقة Team 127 دولارًا شهريًا (حوالي 1,385 دولارًا فاتورة سنويًا) لـ 50 تكاملًا؛ وتكلفة Enterprise مخصصة. Apidog مجاني لما يصل إلى 4 مستخدمين، مع خطط مدفوعة تبدأ من 9 دولارات لكل مستخدم شهريًا، تتضمن أدوات العقود بدلاً من الفوترة كوسيط منفصل. هل تقارن أدوات الالتقاط وإعادة التشغيل أيضًا؟ انظر أفضل بديل لـ Keploy.

تخلّص من الروتين الزائد، وحافظ على العقد

إذا كان إعداد Pact الخاص بك موجودًا لاكتشاف تباين المخطط (schema drift)، فيمكنك الحصول على هذا الضمان من مواصفة واحدة، يتم التحقق منها في كل عملية تشغيل، باستخدام النماذج الوهمية التي يرغبها مستهلكوك بالفعل. قم باستيراد ملف OpenAPI الخاص بك، وادمج apidog run في CI، ووزع عنوان URL للنماذج الوهمية. قم بتنزيل Apidog أو ابدأ في المتصفح؛ فريق مكون من 4 أفراد لا يدفع شيئًا، والوسيط الذي لم تعد تصونه هو بيت القصيد.