لماذا يحتاج اختبار تكامل API إلى رسم بياني صريح
| الترتيب يصبح عَرَضيًا | تنجح الاختبارات بالترتيب الذي اختاره المشغّل مصادفةً، ثم تفشل على جهاز آخر. فيضيف أحدهم إضافة لترتيب التنفيذ، فتصبح المشكلة دائمة. |
| إخفاق واحد يبدو كعشرين | يفشل طلب الإنشاء، فيفشل كل ما يأتي بعده، وتحصل على شاشة حمراء بالكامل. ويصبح العثور على أول إخفاق حقيقي هو المهمة نفسها. |
| التوازي غير آمن | من دون معرفة ما الذي يعتمد على ماذا، لا يمكنك تشغيل أي شيء بالتوازي بأمان. لذا تبقى مجموعات الاختبار متسلسلة وبطيئة. |
جعله صريحًا
الحل أن يعلن كل اختبار ما يحتاج إليه وما ينتجه. وبمجرد توفّر ذلك، يستنتج المشغّل ترتيبًا آمنًا، وتعمل الفروع المستقلة بالتوازي، ويجعل الإخفاقُ الاختباراتِ المعتمدة عليه متخطّاة لا فاشلة. فتتحوّل عشرون صفًا أحمر إلى إخفاق واحد وتسعة عشر تخطّيًا، وهي تجربة تصحيح مختلفة تمامًا.
هذا هو الفرق بين Endpoint Tests التي تغطّي مسارًا واحدًا في كل مرة، وبين Integration Tests وهي سلاسل متعددة الخطوات تُغذّي فيها استجابةُ خطوةٍ الخطوةَ التالية.
مشكلة تمرير القيم
يُعيد طلب الإنشاء معرّفًا تحتاج إليه الخطوات اللاحقة. إن ثبّتّه في الشيفرة نجح الاختبار مرة واحدة فقط. وإن التقطته، حملت السلسلة البيانات إلى الأمام كما ينبغي. يبدو هذا بديهيًا حين يُكتب، وهو السبب الأكثر شيوعًا في أن تفشل اليوم مجموعة اختبارات كانت ناجحة الشهر الماضي.
التنظيف داخل السلسلة
تُنشئ اختبارات التكامل حالةً أكثر مما تُنشئه اختبارات نقاط النهاية، وتُنشئها بترتيب اعتمادية يجب أن يحترمه التفكيك. لا يمكنك حذف العميل قبل الطلب. والتنظيف المرتبط بما أنشأته الجولة نفسها، بترتيب اعتمادية عكسي، هو النسخة الوحيدة التي تصمد مع التنفيذ المتزامن.
أربعة أمور تحدّد ما إذا كانت مجموعة اختبارات API ستصمد سنتها الأولى: جلسات تنتهي صلاحيتها، وقيم لا توجد إلا في وقت التشغيل، ونداءات يعتمد بعضها على بعض، وسجلات لا ينظّفها أحد. تعالج TestSprite هذه الأمور عبر Auto-Authentication وDynamic Variables وDependency Chains وAuto-Cleanup، الموضّحة في توثيق اختبار API.
ماذا تفعل حين تفشل السلسلة عند الخطوة الرابعة
تتجلّى قيمة إعلان الاعتماديات بأوضح صورة في شكل الإخفاق نفسه، ومن المفيد معرفة ترتيب القراءة.
أولًا، تحقّق ممّا إذا كان الإخفاق في الخطوة نفسها أم في مدخلاتها. فالخطوة التي تلقّت معرّفًا خاطئًا أخفقت لأن شيئًا سابقًا لها أنتج القيمة الخاطئة، وإصلاح الخطوة إنما هو إصلاح للعَرَض.
ثانيًا، تحقّق ممّا إذا كانت تفشل انطلاقًا من حالة نظيفة. فالسلسلة التي تنجح مرة وتفشل عند إعادة التشغيل تخبرك بأن التنظيف لم يحدث، وهذا خلل مختلف عن الذي تبحث عنه، وغالبًا ما يكون الأهم.
ثالثًا، وعندها فقط انظر إلى نقطة النهاية نفسها. ففي أغلب الأحيان تكون المعلومة المهمة في الفحصين الأولين، ولهذا تكلّف قائمةٌ مسطّحة من الصفوف الحمراء جهدًا في التصحيح أكبر بكثير من رسم بياني فيه إخفاق واحد وتسعة عشر تخطّيًا.
أبقِ السلاسل قصيرة
السلسلة المكوّنة من اثنتي عشرة خطوة والتي تفشل عند الخطوة التاسعة يصعب تشخيصها ويبطؤ إعادة تشغيلها. أما ثلاث إلى خمس خطوات تغطّي نية واحدة للمستخدم فهي الحجم الذي يبقى مفيدًا. والسلاسل الطويلة تعني عادةً أن رحلتين اندمجتا في واحدة.
كيف تبدأ
الطرفية
npm install -g @testsprite/testsprite-cli
testsprite setup
إن كنت تفضّل ألا تثبّت شيئًا، فلوحة التحكم تؤدي الغرض نفسه. وكل ما يستطيع سطر الأوامر فعله غير ذلك تجده في مستودع CLI.
اربط المستودع من لوحة التحكم لتنطلق الجولات من عملية النشر التي تنتجها أصلًا، أو أضِف خطوة إلى سير عملك الخاص بدلًا من ذلك.
كيف تجعل TestSprite الرسم البياني صريحًا
تُعلن كل حالة اختبار ما تحتاج إليه وما تنتجه، ومن ذلك تستنتج Dependency Chains ترتيب تنفيذ آمنًا. تعمل الفروع المستقلة بالتوازي، وحين يخفق شيء تصبح الحالات المعتمدة عليه متخطّاة لا فاشلة، فتتحوّل عشرون صفًا أحمر إلى إخفاق واحد وتسعة عشر تخطّيًا.
تتكفّل Dynamic Variables بتمرير القيم، فتحمل السلسلة المعرّف الذي أعاده نداء الإنشاء بدل رقم لصقه أحدهم. وتحذف Auto-Cleanup ما أنشأته كل جولة، بترتيب اعتمادية عكسي، وهو ما يجعل الجولات المتزامنة آمنة.
تظهر الفائدة في أول مرة تنكسر فيها سلسلة. تحصل على إخفاق واحد يحدّد موضع الانحراف بدل شاشة حمراء عليك أن تقرأها كلها، وهذا هو الفرق بين تشخيص يستغرق خمس دقائق وتشخيص يستغرق بعد ظهر كامل.
كيف يختلف هذا عن الاختبار من طرف إلى طرف؟
يعني الاختبار من طرف إلى طرف عادةً المرور عبر الواجهة. أما اختبار تكامل API فيختبر الرحلات نفسها عند طبقة الخدمة، وهو أسرع وأدقّ في تحديد موضع وقوع الإخفاق.
هل ينبغي أن تستخدم اختبارات التكامل اعتماديات حقيقية؟
في اختبار التكامل، نعم، فهذا هو المقصود. ومحاكاة الطرف الذي تتكامل معه تجيب عن سؤال آخر.
كيف نتعامل مع بيانات الاختبار بين الخطوات؟
التقط ما تنتجه كل خطوة ومرّره إلى ما بعدها. والبيانات المزروعة المشتركة مريحة إلى أن تمسّ سلسلتان السجل نفسه.
وماذا عن خدمات الطرف الثالث داخل السلسلة؟
استخدم بيئتها التجريبية المعزولة إن وُجدت. وحيث لا توجد، اعزل تلك الخطوة واقبل أن للسلسلة حدًّا تقف عنده.
كم اختبار تكامل نحتاج؟
واحدًا لكل رحلة مستخدم مهمة، لا واحدًا لكل تركيبة من نقاط النهاية. فالتركيبات لا نهاية لها، أما الرحلات فلها نهاية.
أعلِن الرسم البياني، أو صحّح أخطاءه إلى الأبد.
اختبار تكامل API يدور حول التسلسلات، وللتسلسلات رسم بياني للاعتماديات. وإعلان ما يحتاج إليه كل اختبار وما ينتجه يمنحك ترتيبًا آمنًا وتوازيًا وإخفاقات قابلة للقراءة. التقط القيم بدل تثبيتها في الشيفرة، وأبقِ السلاسل قصيرة.