اختبار API: ما تفعله أولًا، وما يليه، وما لم يحن وقته بعد

الأنشطة الخمسة داخل اختبار API

• الاختبار الوظيفي. هل تؤدي نقطة النهاية الواحدة ما يُفترض بها، بما في ذلك مع المدخلات الخاطئة؟ ابدأ من هنا. فكل ما عداه يفترض توفّره.

• اختبار التكامل. هل تُنتج التسلسلات النتيجة الصحيحة؟ هنا تكمن فعليًا معظم العيوب التي يراها المستخدم.

• اختبار العقود. هل تتفق خدمتان على الشكل؟ مفيد مع عمليات النشر المستقلة، لكنه لا يرى الصحّة.

أما الاثنان الآخران فهما الحِمل، الذي يجيب عن سؤال السعة ويحتاج مولّدًا مخصصًا، إضافةً إلى السلوك الأمني، وهو في معظمه فحوص للتفويض، ومكانه إلى جانب التغطية الوظيفية لا في تمرين رُبع سنوي.

الترتيب الذي يستحق اتّباعه

1. الوظيفي، على نقاط النهاية المهمة. بما في ذلك الحالات السلبية. فكل ما عداه مبني على هذا.

2. التكامل، على رحلات المستخدم الحقيقية لديك. من ثلاث إلى خمس خطوات لكل رحلة، لا اثنتي عشرة.

3. فحوص التفويض في كل مكان. رخيصة، والتفويض على مستوى الكائن هو أكثر ثغرات API استغلالًا.

4. العقود، إن كانت الخدمات تُنشر بشكل مستقل. تجاوزه إن كنت تنشر كل شيء معًا.

5. الحِمل، قبل الإصدارات. أخيرًا، لأن اختبار الحِمل على نقطة نهاية غير صحيحة يقيس سرعتك في الخطأ.

المشكلات الأربع، أيًّا كانت الأداة التي تختارها

أربعة أمور تحدّد ما إذا كانت مجموعة اختبارات API ستصمد سنتها الأولى: الجلسات التي تنتهي صلاحيتها، والقيم التي لا توجد إلا في وقت التشغيل، والاستدعاءات التي يعتمد بعضها على بعض، والسجلات التي لا ينظّفها أحد. وتعالج TestSprite هذه الأمور عبر Auto-Authentication وDynamic Variables وDependency Chains وAuto-Cleanup، الموصوفة في توثيق اختبار API.

كل فريق يواجه هذه الأمور بالترتيب نفسه، ومعظم الفرق تواجهها على حين غِرّة. والتصميم لها هو الفارق بين مجموعة اختبارات تدوم وأخرى ينتهي بها الأمر إلى العزل.

التوكيد الأهم على الإطلاق

أكِّد على جسم الاستجابة، لا على رمز الحالة وحده. فاستجابة 200 تحمل قائمة فارغة حيث ينبغي أن يكون هناك سجل هي عيب يعدّه فحص الحالة نجاحًا. وهذه العادة وحدها تكشف من العيوب الحقيقية أكثر مما يكشفه أي تغيير منفرد آخر.

أول عشر حالات، بشكل ملموس

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

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

عشر حالات، عمل صباح واحد، وهي تغطي الأنماط التي تنتج عنها معظم الحوادث. والتوسّع بعدها ينبغي أن يقوده ما يحدث من أخطاء فعلية لا هدف تغطية، لأن الأسلوب الثاني يُنتج مجموعات اختبارات كبيرة وبعيدة عن الغرض.

من أين تبدأ اليوم

وجّه مشروعًا إلى خدمتك، ودع الاكتشاف يُحصي ما هو موجود، واقرأ الخطة المولَّدة قبل تشغيل أي شيء. فالخطة تخبرك عن الـ API لديك أكثر مما ستخبرك به النتائج الأولى، وهي الموضع الذي تُضاف فيه معرفتك بالمنتج.

وإن كنت تفضّل ألا تثبّت شيئًا، فلوحة التحكم تؤدي الغرض نفسه. أما كل ما يمكن لسطر الأوامر فعله غير ذلك فتجده في مستودع CLI.

• GitHub App هو خطّاف ويب تُعدّه في لوحة تحكم TestSprite. يستمع إلى حدث النشر الذي ينتجه مسار النشر لديك بالفعل، فلا يتغير شيء في مستودعك.

• GitHub Actions يضع الخطوة داخل سير عملك الخاص، ويُضبط من الطرفية.

أين تقع TestSprite بين الخمسة

الوظيفي والتكامل والنصف السلوكي من الأمان. فهي تُشغّل الخدمة العاملة وتختبرها، وتولّد الخطط من جولة اكتشاف إضافةً إلى مواصفاتك، وتغطي الحالات السلبية التي تتخطاها المجموعات المكتوبة يدويًا.

تُبقي Auto-Authentication الجلسات حيّة طوال التشغيل، وتنقل Dynamic Variables القيم بين الاستدعاءات، وتستنتج Dependency Chains ترتيب التنفيذ مما تحتاجه كل حالة وما تنتجه، وتزيل Auto-Cleanup ما أنشأه التشغيل بالضبط. وهذه الأربعة هي ما يحدّد صمود أي مجموعة اختبارات في سنتها الأولى، في أي أداة كانت، ووجودها كجزء من المنتج هو الفارق بين توسيع المجموعة وصيانتها.

يبقى اختبار العقود واختبار الحِمل أداتين منفصلتين، وهذا يعمل إلى جانبهما. وما تحصل عليه هو الطبقة التي تعيش فيها معظم العيوب التي يراها المستخدم، مغطاةً دون إطار عمل خاص بك، وتعمل مع كل طلب سحب.