واجهات API عامة للتدرّب على اختبارها

كيف تستخدم قائمة واجهات API العامة هذه

اختر واجهة API واحدة ومهارة واحدة. اكتب ثلاث حالات: المسار السليم، وحالة حدّية واحدة، وحالة ثالثة تتوقّع فيها الإخفاق وتتحقّق من أن شكل الخطأ صحيح. هذه الحالة الثالثة هي التي يتخطّاها معظم الناس، وهي التي تفصل بين مجموعة اختبارات تكشف العلل ومجموعة تكتفي بتأكيد أن الخدمة تعمل.

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

لتعلّم أساسيات الطلب والاستجابة

• JSONPlaceholder. واجهة REST API وهمية تضمّ منشورات وتعليقات ومستخدمين ومهامّ. تقبل عمليات الكتابة وتتظاهر بحفظها. تدرّب على: أفعال CRUD، ورموز الحالة، والفرق بين طلب نجح وتغيير حُفظ فعلًا. وكون عمليات الكتابة لا تُحفظ حقًّا يجعلها درسًا بالغ الفائدة في التحقّق من النتائج بدلًا من الاكتفاء بالاستجابات.

• HTTPBin. نقطة نهاية تُعيد إليك ما ترسله، إضافة إلى مسارات تُعيد أي رمز حالة تطلبه، أو تتأخّر عمدًا، أو تُعيد حمولات مشوَّهة. تدرّب على: المهل الزمنية، وإعادة المحاولة، والتعامل مع عمليات إعادة التوجيه، وسلوك الترويسات. وإن أردت أن ترى كيف تتفاعل مجموعة اختباراتك مع رمز 503، فبإمكانك توليده متى شئت.

• REST Countries. بيانات عن الدول بهيكل ثابت وموثَّق جيدًا، ولا تتطلّب مفتاحًا. تدرّب على: التحقّق من المخطط والتحقّق على مستوى الحقول في حمولة كبيرة بما يكفي لتكون مثيرة للاهتمام، وصغيرة بما يكفي لقراءتها.

للتقسيم إلى صفحات والمجموعات الكبيرة

للمصادقة وحدود المعدّل

ثلاث عمليات تحقّق تستحقّ التدرّب عليها مع أي واجهة API عامة

أيًّا كانت الخدمة التي تختارها، فهذه هي العادات التي ستنتقل معك إلى واجهة API الخاصة بك.

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

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

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

توجيه وكيل إلى إحداها

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

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

• هل يلتقط القيم بدلًا من ترميزها بشكل ثابت؟ استدعاء الإنشاء يُعيد معرّفًا، والاستدعاء التالي ينبغي أن يستخدمه. والمعرّفات المرمَّزة بشكل ثابت هي السبب المعتاد في أن تعمل مجموعة الاختبارات مرة واحدة فقط.

• هل يرتّب الاستدعاءات المترابطة ترتيبًا صحيحًا؟ لا يمكنك جلب تعليق على منشور لم يُنشأ أصلًا. راقب ما إذا كانت الخطة تدرك ذلك أم أنها تكتفي بسرد نقاط النهاية أبجديًا.

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

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

الانتقال من التدريب إلى خدمتك الخاصة

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

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

لا يظهر أي من ذلك في الدروس التعليمية، ويظهر كله في الأسبوع الأول. لذا تعامل مع مرحلة واجهات API العامة على أنها تعلّم لعمليات التحقّق، وهي تنتقل معك بالكامل، وتوقّع أن يكون التعامل مع الحالة أمرًا منفصلًا تتعلّمه لاحقًا لا امتدادًا للمهارة نفسها.

ما ينبغي تجنّبه مع هذه الواجهات

• لا تستخدمها في اختبار الأحمال. فهي مجانية ومشتركة، وثمة من يدفع فاتورتها.

• لا تبنِ اعتمادًا إنتاجيًا على أي منها. فالشروط تتغيّر، والمشاريع تُؤرشَف، والمتطوّعون يتعبون.

• لا تعتبر نجاح مجموعة اختبارات على JSONPlaceholder دليلًا على صحّة واجهة API الخاصة بك. فهو يخبرك أن إعداد اختباراتك يعمل، وهذا ادّعاء مفيد فعلًا لكنه أصغر بكثير.

تجربة ذلك على خدمة حقيقية

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

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

وتجربته أولًا على واجهة API عامة أمر آمن، إذ لا توجد بيانات تُلوَّث، والخطة تخبرك عن الأداة أكثر مما ستخبرك به النتائج.