إن كتابة نص برمجي للاختبار الآلي أمر سهل. الجزء الصعب هو كتابة نص يحتفظ بمكانته بعد ستة أشهر. يتم كتابة الكثير من نصوص الاختبار وتشغيلها بنجاح مرة واحدة، ثم تتعفن بصمت، وتتوقف عن العمل بسبب تغييرات غير ذات صلة، ولا تتحقق من أي شيء ذي معنى، وتدرب الفريق على تجاهل الإصدارات الفاشلة. نص الاختبار الجيد يكون دقيقًا ومعزولًا ومتينًا.
يغطي هذا الدليل ماهية النص البرمجي للاختبار الآلي، والبنية التي تجعله موثوقًا به، وطريقتين لكتابة نصوص اختبار API، وبناءً خطوة بخطوة في Apidog.
ما هو النص البرمجي للاختبار الآلي
النص البرمجي للاختبار الآلي هو مجموعة محددة وقابلة للتكرار من التعليمات التي تختبر جزءًا من برنامجك وتتحقق من النتيجة، دون تدخل بشري لتشغيل الخطوات. يرسل النص البرمجي إدخالًا، ويؤدي إجراءً، ويقارن النتيجة بالتوقع. إذا تطابقا، ينجح الاختبار. وإذا لم يتطابقا، يفشل الاختبار ويبلغ عن السبب.
النص البرمجي للاختبار هو الشكل القابل للتنفيذ لـ حالة الاختبار. تصف حالة الاختبار القصد، والإدخال، والإجراء، والنتيجة المتوقعة، بعبارات بشرية. يحول النص البرمجي هذا القصد إلى شيء تشغله الآلة في كل عملية "commit". يمكن أن تتحول حالة اختبار واحدة إلى نص برمجي واحد؛ وعادة ما يصبح سيناريو الاختبار عدة نصوص متسلسلة معًا.
القيمة الكاملة للنص البرمجي للاختبار الآلي تكمن في أنه يعمل بنفس الطريقة في كل مرة. وهذا لا يصدق إلا إذا كان النص البرمجي مكتوبًا ليكون حتميًا. النص البرمجي الذي يعتمد على ترتيب تشغيل نصوص برمجية أخرى، أو على بيانات خلفها تشغيل سابق، ليس أتمتة موثوقة؛ بل هو عبء غير مستقر.
بنية نص الاختبار الموثوق به
تقريبًا كل نص اختبار مكتوب جيدًا، بأي لغة أو أداة، يتبع نفس الشكل المكون من أربعة أجزاء. غالبًا ما يطلق عليه "الترتيب-التنفيذ-التحقق" (Arrange-Act-Assert)، مع إضافة التنظيف.
الترتيب (Arrange). قم بإعداد كل ما يحتاجه الاختبار: بيانات الإدخال، المصادقة، أي شروط مسبقة. يجب أن ينشئ النص البرمجي حالته الخاصة بدلاً من افتراض وجودها. إذا كان الاختبار يحتاج إلى مستخدم، فإنه ينشئ مستخدمًا، أو يستخدم تثبيتًا معروفًا، وليس ما هو موجود بالصدفة في قاعدة البيانات.
التنفيذ (Act). قم بإجراء الإجراء الوحيد قيد الاختبار. يختبر النص البرمجي الجيد سلوكًا واحدًا. إرسال طلب، استدعاء دالة، تشغيل حدث، هذا هو الإجراء، ويجب أن يكون هناك واحد فقط لكل نص برمجي.
التحقق (Assert). تحقق من النتيجة مقابل التوقعات. هذا هو الجزء الذي لا تستثمر فيه الفرق بالقدر الكافي. النص البرمجي الذي يؤكد فقط "لم يتم طرح أي خطأ" أو "كانت الحالة 200" بالكاد يختبر أي شيء. تقوم التحققات القوية بفحص القيم الفعلية: نص الاستجابة، المخطط، الآثار الجانبية، التوقيت.
التنظيف (Cleanup). تراجع عما أنشأه النص البرمجي حتى يتمكن من التشغيل مرة أخرى من نقطة البداية النظيفة. النص البرمجي الذي يترك بيانات اختبار خلفه سيتعارض في النهاية مع نفسه أو مع نص برمجي آخر.
تفصل ثلاث عادات النصوص البرمجية المتينة عن النصوص الهشة. اختبر شيئًا واحدًا لكل نص برمجي، بحيث يكون للفشل سبب واحد واضح. حافظ على استقلالية النصوص البرمجية، بحيث تعمل بأي ترتيب. وتحقق من القيم المستقرة، وليس أبدًا من البيانات المتقلبة مثل المعرفات المُنشأة أو الطوابع الزمنية، مما يجعل النص البرمجي يفشل بدون سبب حقيقي.
طريقتان لكتابة نصوص اختبار API
بالنسبة لاختبار API على وجه التحديد، هناك طريقتان شائعتان، وتناسبان فرقًا مختلفة.
النهج القائم على الكود أولاً (The code-first approach) يكتب نصوص الاختبار بلغة عامة الغرض. في بايثون، يعني ذلك إطار عمل مثل pytest بالإضافة إلى مكتبة HTTP؛ في جافاسكريبت، مشغل اختبار بالإضافة إلى fetch. تكتب الطلب، والتحققات، والإعداد ككود فعلي، وتعيش النصوص البرمجية في مستودعك جنبًا إلى جنب مع التطبيق.
يوفر هذا النهج تحكمًا برمجيًا كاملًا. المنطق المعقد، والإعدادات المخصصة (custom fixtures)، والتحققات غير العادية كلها مجرد كود. التكلفة هي أن كل نص برمجي هو كود تكتبه وتصينه، ويحتاج الفريق إلى مهارات اللغة، ويتم إعادة كتابة الكثير من الأكواد النمطية (boilerplate)، ومعالجة المصادقة، وبناء الطلبات، وتحليل الاستجابات، عبر النصوص البرمجية. يناسب هذا النهج الفرق الهندسية التي ترغب في إصدار الاختبارات مع الكود وتشعر بالراحة في تحمل مسؤولية هذا الصيانة.
النهج المرئي (The visual approach) يبني نص الاختبار في أداة مخصصة لاختبار API. تحدد الطلب، وتضيف التحققات بالنقر، وتسلسل الطلبات في سيناريوهات، دون كتابة أو صيانة كود نصي للحالات الشائعة. تتبع أدوات مثل Apidog هذا المسار.
يزيل هذا النهج الأكواد النمطية ويجعل النصوص البرمجية قابلة للقراءة من قبل أي شخص في الفريق، وليس فقط من يعرفون اللغة. ما زلت تلجأ إلى الكود المخصص للمنطق النادر الذي لا يستطيع البناء المرئي التعبير عنه. يناسب هذا النهج الفرق المختلطة، والاختبارات التي يقودها فريق ضمان الجودة (QA)، وأي شخص يريد تشغيل مجموعة اختبار بسرعة دون الحاجة إلى مشروع برمجي مرفق.
كلاهما ليس خاطئًا. السؤال الحاسم هو من يقوم بصيانة النصوص البرمجية وما إذا كان يجب أن تعيش في مستودع التطبيق. بالنسبة لمعظم اختبارات API، يوفر النهج المرئي مجموعة موثوقة تعمل بشكل أسرع وبتكاليف صيانة أقل.
كتابة نص برمجي لاختبار API آلي في Apidog
فيما يلي التدفق الكامل لبناء نص برمجي لاختبار API متين بصريًا.
الخطوة 1: تحديد الطلب. قم بإحضار نقطة النهاية (endpoint) إلى Apidog من ملف OpenAPI أو عرفها مباشرة. هذه هي خطوة الترتيب (Arrange)؛ يحمل الطلب طريقته، مساره، رؤوسه (headers)، وجسمه (body).
الخطوة 2: إضافة بيانات الاختبار. قم بتعيين حمولة الإدخال (input payload) للحالة التي تختبرها. لتغطية العديد من المدخلات بنص برمجي واحد، أرفق ملف CSV أو JSON بحيث يعمل النص البرمجي مرة واحدة لكل صف؛ الاختبار القائم على البيانات يستبدل عشرات النصوص البرمجية المتطابقة تقريبًا بنص واحد.
الخطوة 3: كتابة التحققات. هذا هو الجوهر. أضف فحوصات بصرية: الحالة تساوي الكود المتوقع، وحقول الجسم الرئيسية موجودة ولها القيم الصحيحة، وتتطابق الاستجابة مع المخطط، ووقت الاستجابة ضمن الميزانية. للحالات السلبية، تحقق من شكل الخطأ، وليس فقط كود الفشل. قاوم الرغبة في التحقق من البيانات المتقلبة.
الخطوة 4: تسلسل الطلبات في سيناريو. تمتد سير العمل الحقيقي عبر عدة مكالمات. قم ببناء سيناريو يقوم بتسجيل الدخول، وإنشاء مورد، وقراءته، وحذفه، وتمرير القيم من خطوة إلى أخرى. كل خطوة هي نص برمجي؛ تختبر معًا تدفقًا كاملًا.
الخطوة 5: أضف منطق النص البرمجي المخصص فقط عند الحاجة. للفحوصات التي لا تستطيع التحققات المرئية التعبير عنها، والمنطق الشرطي، والقيم المحسوبة، والمقارنات عبر الطلبات، أضف معالجًا مسبقًا أو لاحقًا (pre- or post-processor) بلغة JavaScript. اجعل هذا الحد الأدنى؛ فمعظم النصوص البرمجية لا تحتاجه أبدًا.
الخطوة 6: تشغيله وقراءة التقرير. نفذ السيناريو. يقوم Apidog بتشغيل كل نص برمجي، ويقيم كل تحقق، ويبلغ عن الفحص المحدد الذي فشل مع القيم المتوقعة والفعلية جنبًا إلى جنب.
الخطوة 7: أتمتة التشغيل. قم بربط السيناريو بـ CI/CD بحيث يعمل في كل عملية "commit". نص الاختبار الذي يعمل فقط عندما يتذكره شخص ما ليس آليًا حقًا. قم بتنزيل Apidog لبناء أول سيناريو لك.
الحفاظ على صحة نصوص الاختبار
مجموعة الاختبار (test suite) هي شيء حي. النصوص البرمجية التي كانت مثالية عند الإصدار تتأخر عن مواكبة التحديثات مع تغير API. ثلاث ممارسات تحافظ على موثوقية المجموعة.
حدث النصوص البرمجية مع API، وليس بعده. عندما يتغير عقد نقطة النهاية (endpoint)، يتغير النص البرمجي في نفس الالتزام (commit). النص البرمجي الذي يؤكد مخططًا قديمًا يفشل لسبب خاطئ ويقوض الثقة في كل نص برمجي آخر.
تعامل مع النصوص البرمجية المتقلبة (flaky scripts) كأخطاء حقيقية. النص البرمجي الذي ينجح معظم الوقت أسوأ من عدم وجود نص برمجي على الإطلاق، لأنه يعلم الفريق أن اللون الأحمر لا يعني وجود مشكلة. تتبع السبب، وهو عادة حالة مشتركة أو افتراض توقيت، وقم بإصلاحه.
راجع النصوص البرمجية ككود الإنتاج. النص البرمجي الذي يحتوي على تحققات ضعيفة، أو فحص 200 فقط، يبدو أخضر ويشعر بالأمان بينما لا يختبر شيئًا تقريبًا. يمكن لقارئ ثانٍ اكتشاف ذلك.
الأسئلة المتكررة
ما الفرق بين حالة الاختبار والنص البرمجي للاختبار؟ تصف حالة الاختبار القصد بعبارات بشرية: الإدخال، الإجراء، النتيجة المتوقعة. النص البرمجي للاختبار هو النسخة التنفيذية التي تشغلها الآلة. الحالة هي الخطة؛ النص البرمجي هو التنفيذ.
هل أحتاج إلى معرفة كيفية البرمجة لكتابة نصوص اختبار آلية؟ ليس لاختبار API باستخدام أداة مرئية. في Apidog، تقوم ببناء الطلبات، والتحققات، والسيناريوهات بالنقر، وتكتب الكود فقط للمنطق غير العادي. تتطلب أطر العمل القائمة على الكود أولاً مهارات اللغة.
لماذا تستمر نصوص الاختبار الخاصة بي في التعطل؟ الأسباب المعتادة هي التحقق من البيانات المتقلبة، واعتماد النصوص البرمجية على حالة بعضها البعض، وعدم تحديث النصوص البرمجية عند تغير API. اعزل بيانات الاختبار، واجعل النصوص البرمجية مستقلة، وقم بتحديثها مع العقد.
كم عدد التحققات التي يجب أن يحتوي عليها نص الاختبار الواحد؟ ما يكفي للتحقق الفعلي من النتيجة، عادة الحالة، وحقول الجسم الرئيسية، والمخطط، والتوقيت. تحقق واحد لرمز الحالة قليل جدًا؛ فهو ينجح بينما الاستجابة خاطئة.
هل يجب أن تعيش نصوص الاختبار في مستودع التطبيق؟ باستخدام النهج القائم على الكود أولاً، عادة نعم، بحيث يتم إصدار الاختبارات مع الكود. باستخدام أداة مرئية، تعيش النصوص البرمجية في منصة الاختبار وتتزامن مع تعريف API بدلاً من ذلك. كلاهما يعمل؛ الاتساق يهم أكثر من الاختيار.
كيف أكتب نصوص الاختبار قبل بناء API؟ اكتبها بناءً على تصميم API. إذا كان لديك مواصفات OpenAPI، يمكنك تعريف الطلبات والتحققات منها، ثم تشغيلها مقابل خادم وهمي (mock server) حتى يتم إنشاء نقطة النهاية الحقيقية. تكون النصوص البرمجية جاهزة لحظة وصول التنفيذ.
ما الفرق بين نص الاختبار ومجموعة الاختبار؟ نص الاختبار يجري فحصًا واحدًا. مجموعة الاختبار (test suite) هي مجموعة من النصوص البرمجية المجمعة لتشغيلها معًا، غالبًا ما تغطي API أو ميزة كاملة. تحافظ المجموعات على تنظيم مجموعة متزايدة من النصوص البرمجية وتتيح لك تشغيل تغطية واسعة في أمر واحد.
ما المدة التي يجب أن يستغرقها نص الاختبار الآلي؟ أقصر ما يمكنه أن يكون مع الاستمرار في أداء الأجزاء الأربعة: الترتيب، التنفيذ، التحقق، التنظيف. إذا كان النص البرمجي طويلاً، فإنه عادةً ما يختبر أكثر من شيء واحد ويجب تقسيمه. سلوك واحد لكل نص برمجي يجعل تشخيص الأعطال سهلاً.