الخلاصة أولًا
-
اختر Postman إذا كنت تستكشف واجهة API أو توثّقها أو تشارك طلبات قابلة لإعادة التنفيذ مع أشخاص لن يكتبوا شيفرة اختبارات.
-
اختر TestSprite إذا أردت تغطية API مُولَّدة مما تكشفه الخدمة فعليًا، وتتولى الجلسة والحالة والترتيب والتنظيف كجزء من المنتج.
-
شغّل الاثنين معًا إذا كانت مجموعتك تؤدي دورًا حقيقيًا. احتفظ بها للاستكشاف والتوثيق، ودع التغطية المُولَّدة تحمل عبء اختبارات الانحدار.
جنبًا إلى جنب
| المحور | Postman | TestSprite |
|---|---|---|
| أبرز نقاط القوة | استكشاف الطلبات وتوثيقها ومشاركتها | توليد تغطية لما تكشفه الخدمة وصيانتها |
| كيف تُبنى التغطية | يضيف أحدهم كل طلب ويكتب التحققات داخل سكربت | تُولَّد من مواصفة أو من جولة اكتشاف، ثم تُصقل |
| إدارة الجلسة | سكربتات ما قبل الطلب تكتبها وتصونها بنفسك | Auto-Authentication، يُضبط مرة واحدة |
| القيم المتنقلة بين الاستدعاءات | متغيرات بيئة تُضبط داخل السكربتات | Dynamic Variables، موصولة من الاستجابة |
| ترتيب التنفيذ | ترتيب المجموعة، يُدار يدويًا | مُستنتج مما يحتاجه كل اختبار وما يُنتجه |
| التنظيف | ما تكتبه أنت في السكربتات | Auto-Cleanup مرتبط بما أنشأه التشغيل |
| الاستخدام الأنسب | الاستكشاف والتوثيق والتحقق اليدوي | اتساع تغطية الانحدار دون فريق QA مخصص |
تفاصيل عمل هذه الأربع موجودة في توثيق اختبار API.
أين يتفوق Postman فعلًا
استكشاف واجهة API غير مألوفة. لا شيء يضاهي تجربة نقاط النهاية يدويًا وأنت ما زلت تتعرف على ما تفعله.
مشاركة حالة قابلة لإعادة الإنتاج. مجموعة يستطيع أي شخص استيرادها وتشغيلها هي أوضح تقرير خلل يمكن أن يصل إلى فريق API.
توثيق حي. طلبات هي أمثلة في الوقت نفسه، محفوظة إلى جانب واجهة API التي تصفها.
أين تصبح المجموعات المعتمدة على السكربتات مكلفة
كل مجموعة جادة ينتهي بها الأمر إلى تراكم كتلة من سكربتات ما قبل الطلب وسكربتات الاختبار التي تتعامل مع الرموز، وتلتقط المعرّفات، وتفرض الترتيب، وتنظّف بعد الانتهاء. هذا إطار عمل صغير مكتوب بلغة JavaScript، مدفون داخل أداة لم تُصمَّم أصلًا لتكون إطار عمل، ولا يفهمه عادةً سوى شخص واحد.
وهو يعمل بالفعل. لكن الثمن أن يتحول الشخص الذي يفهمه إلى نقطة اعتماد، وأن تُعزل المجموعة بدل إصلاحها حين تتحول إلى اللون الأحمر.
حين تكون المجموعة هي التوثيق
هناك حالة تؤدي فيها المجموعة دورًا لا تعوّضه أي حزمة مُولَّدة، ويستحق الحماية بدل دمجه والاستغناء عنه.
إذا كانت مجموعتك هي ما يستورده مستهلك خارجي ليتعلم واجهة API لديك، فهي توثيق مزوّد بزر تشغيل، وقيمتها في أن يقرأها شخص غريب عن المشروع فيفهمها. وهذا يستدعي إبقاءها صغيرة ومنتقاة وقائمة على الأمثلة، وهو عكس ما تحتاجه حزمة اختبارات الانحدار تمامًا. أما مجموعة تضخّمت إلى أربعمائة طلب مع إعداد مكتوب بالسكربتات فلم تعد تخدم ذلك الغرض، وعلى الأرجح لم تعد كذلك منذ فترة.
الفصل النظيف هو أن تكون المجموعة هي الباب الأمامي، وأن يتولى شيء آخر دور شبكة الأمان. فالاثنان يشدّان في اتجاهين مختلفين، ومحاولة جعل مُخرَج واحد يؤدي الدورين معًا هي السبب في أن كثيرًا من المجموعات تنتهي بلا قابلية للقراءة ولا جدارة بالثقة.
تشغيل الاثنين معًا
احتفظ بالمجموعة للاستكشاف والتوثيق وإعادة إنتاج الحالات، ودع التغطية المُولَّدة تتولى نقاط النهاية وسلاسل التكامل التي يجب أن تستمر في العمل. وهما لا يتداخلان كثيرًا في الممارسة العملية، لأن كل واحد منهما يجيب عن سؤال مختلف.
إن كنت في مرحلة التقييم، فاكسر شيئًا عن قصد
أدخِل انحدارًا حقيقيًا، مثل زر حفظ لم يعد يحفظ فعليًا، وراقب ما تبلّغ عنه كل أداة. ثلاثة أسئلة: هل يفشل الاختبار، وهل يسمّي الفشل الانحراف الفعلي، وهل يستطيع الشخص أو الوكيل الذي سيصلحه أن ينطلق من ذلك المخرَج دون إعادة استنتاج القصة من جديد. والأداة التي تبلّغ عن نجاح في تشغيل لم يصل أصلًا إلى تحققاته تكون قد رسبت في الاختبار الوحيد المهم.
اربط المستودع من لوحة التحكم لتبدأ عمليات التشغيل من النشر الذي تنتجه أصلًا، أو أضف خطوة إلى سير العمل الخاص بك بدلًا من ذلك. وكلتا الطريقتين موصوفة في مستودع CLI.
ما يتولاه TestSprite ولا ينبغي أن تتولاه المجموعة
اتساع تغطية الانحدار، مع معالجة مشكلات الحالة الأربع كجزء من المنتج: Auto-Authentication للجلسات، وDynamic Variables للقيم التي لا توجد إلا أثناء التشغيل، وDependency Chains للترتيب، وAuto-Cleanup لما أنشأه التشغيل. وهذه تحديدًا هي الأمور التي تحوّل المجموعة إلى مشروع برمجة سكربتات.
تأتي التغطية من API Discovery على الخدمة العاملة إضافةً إلى مواصفتك، وهو ما يُنتج مسارات الأخطاء والحالات الحدّية التي تتجاوزها المجموعات المبنية يدويًا. وتُجري التحسينات بلغة طبيعية بدلًا من سكربتات ما قبل الطلب.
والفائدة أن مجموعتك تستطيع العودة إلى ما تبرع فيه حقًا: الاستكشاف والتوثيق وتسليم شخص ما حالة قابلة لإعادة الإنتاج يستوردها ويشغّلها. ولا يعود أحد مضطرًا لأن يكون الشخص الذي يفهم سكربت تجديد الرمز.
هل يمكننا استيراد مجموعتنا؟
تعامل مع المجموعة القائمة كمواصفة لما هو موجود، لا كاختبارات تُرحَّل. الجزء المفيد فيها هو جرد نقاط النهاية.
هل يكفي Newman للتكامل المستمر؟
إنه يشغّل المجموعات ضمن التكامل المستمر بكفاءة تامة. المسألة ليست في المُشغِّل، بل في من يصون السكربتات التي تتولى الجلسة والحالة والترتيب والتنظيف.
وماذا عن أدوات المراقبة في Postman؟
جيدة لمراقبة التوافر وفحوص العقود البسيطة. لكنها ليست بديلًا عن تغطية تفهم الاعتماديات بين الاستدعاءات.
هل نفقد توثيقنا؟
لا. لا شيء هنا يحل محل دور التوثيق، وهو أحد الأمور التي يبرع فيها Postman حقًا.
ما حجم التغطية التي نحصل عليها في اليوم الأول؟
جولة اكتشاف مع مواصفة تُنتجان خطة تغطي السطح كاملًا. راجعها واحذف المسارات الإدارية والداخلية قبل تشغيل أي شيء.
احتفظ بالمجموعة للاستكشاف، لا لاختبارات الانحدار.
Postman هو أفضل مكان لاستكشاف واجهة API وتوثيقها. لكن ما إن تتحول المجموعة إلى حزمة اختبارات الانحدار حتى تتحول الجلسة والقيم الملتقطة والترتيب والتنظيف إلى إطار عمل تصونه يدويًا. احتفظ بالاثنين، ودع كل واحد يؤدي الدور الذي يجيده.