DEV Community

Cover image for ما هو اختبار API بلا رأس؟
Yusuf Khalidd
Yusuf Khalidd

Posted on • Originally published at apidog.com

ما هو اختبار API بلا رأس؟

اختبار الـ API بدون واجهة رسومية (Headless API testing) يعني تشغيل اختبارات الـ API من دون أي واجهة رسومية في مسار التنفيذ. بدل فتح تطبيق والنقر يدويًا، تُشغّل الاختبارات من الطرفية أو داخل CI، اعتمادًا على عقد الـ API، ثم تقرأ النتيجة كـ exit code أو سجل نصي أو تقرير منظم. إذا شغّلت اختبارات Apidog CLI داخل عملية بناء، أو استخدمت Newman لتشغيل مجموعة من سطر الأوامر، فأنت تستخدم بالفعل اختبارًا بدون واجهة رسومية.

جرّب Apidog اليوم

اختبار الـ API بدون واجهة رسومية: التعريف العملي

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

اختبار الـ API بدون واجهة رسومية يتميز بثلاث نقاط أساسية:

  • لا توجد GUI أثناء التنفيذ: التشغيل يتم داخل shell، أو container، أو CI job.
  • الاختبار مدفوع بالعقد: تعتمد الحالات على شكل الطلب والاستجابة، مثل OpenAPI أو مجموعة اختبارات مُصدّرة.
  • النتائج قابلة للقراءة آليًا: المخرجات تكون exit codes، أو logs، أو JSON، أو JUnit XML، بحيث يستطيع الـ pipeline اتخاذ قرار النجاح أو الفشل.

مثال بسيط للفكرة:

apidog run ./api-tests.json
Enter fullscreen mode Exit fullscreen mode

أو داخل CI:

apidog run ./api-tests.json -r cli,json
Enter fullscreen mode Exit fullscreen mode

الهدف ليس فقط تشغيل الاختبار، بل جعله جزءًا قابلًا للتكرار من عملية التطوير والنشر.

لماذا يهم عندما يكون الـ API هو المنتج

عندما يكون الـ API الخاص بك هو المنتج، فكل endpoint يمثل وعدًا للمستهلكين. إذا تعطلت نقطة نهاية، فهذا يعني أن جزءًا من المنتج نفسه تعطل.

لهذا لا يكفي أن يقوم شخص بتجربة الواجهة يدويًا قبل كل إصدار. تحتاج إلى اختبارات تعمل تلقائيًا مع:

  • كل commit
  • كل pull request أو merge
  • كل deploy
  • كل تشغيل مجدول ضد staging أو production

المستهلكون الحقيقيون للـ API لا يستخدمون واجهة رسومية. خدمات أخرى تستدعي الـ API، تطبيقات الجوال تستدعيه، ووكلاء الذكاء الاصطناعي قد يستدعونه أيضًا. لذلك يجب أن تكون الاختبارات قريبة من نفس النمط:

  1. إرسال request.
  2. استقبال response.
  3. التحقق من status code والـ headers والـ body.
  4. إرجاع نتيجة واضحة للـ pipeline.

هذا هو الأساس العملي لـ CI/CD قوي لاختبار الـ API.

كيف يختلف عن اختبار الواجهة الرسومية والاختبار اليدوي

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

الجانب الاختبار اليدوي / بالواجهة الرسومية اختبار الـ API بدون واجهة رسومية
المحفز شخص ينقر أو يرسل الطلب أمر، hook، أو مرحلة pipeline
مكان التشغيل تطبيق سطح مكتب أو ويب Terminal، container، CI runner
قابلية التكرار تعتمد على الشخص متطابقة في كل تشغيل
المخرجات مرئية على الشاشة exit codes، logs، JUnit/JSON
التوافق مع CI/CD أصعب في الدمج مصمم لهذا الغرض
الأفضل لـ الاستكشاف وتصحيح الأخطاء regression، gates، scheduled runs

النمط العملي هو:

  1. صمّم الطلب في أداة GUI.
  2. أضف assertions واضحة.
  3. احفظ الحالة ضمن مجموعة أو سيناريو.
  4. شغّلها من CLI داخل CI.

الواجهة الرسومية هي مكان ولادة الاختبار. سطر الأوامر هو مكان تشغيله بشكل دائم.

دور سطر الأوامر CLI

سطر الأوامر هو الطبقة التي تجعل الاختبار headless. الـ CLI runner يأخذ تعريف الاختبار، يشغّله ضد بيئة محددة، ثم يعيد نتيجة يمكن للآلة التعامل معها.

عادةً تحتاج إلى أربع قدرات رئيسية:

1. توجيه الاختبار إلى بيئة محددة

نفس الاختبار يجب أن يعمل ضد staging ثم production بدون نسخه.

مثال عام:

apidog run ./tests.json -e staging
Enter fullscreen mode Exit fullscreen mode

أو:

apidog run ./tests.json -e production
Enter fullscreen mode Exit fullscreen mode

2. تشغيل مدفوع بالبيانات

بدل تكرار نفس حالة الاختبار يدويًا، مرّر بيانات متعددة من CSV أو JSON.

مثال:

apidog run ./tests.json -d users.csv -n 10
Enter fullscreen mode Exit fullscreen mode

هذا النمط مفيد لاختبار حالات مثل:

  • مستخدمون بأدوار مختلفة
  • مدخلات صحيحة وخاطئة
  • حدود القيم
  • حالات edge cases

يمكنك مراجعة الاختبار المعياري من سطر الأوامر لفهم هذا النمط.

3. تقارير قابلة للأرشفة

في CI، لا يكفي أن ترى النتيجة في الطرفية. تحتاج إلى حفظ التقرير.

مثال:

apidog run ./tests.json -r html,cli,json
Enter fullscreen mode Exit fullscreen mode

بهذا تحصل على مخرجات يمكن قراءتها أثناء التشغيل، بالإضافة إلى تقارير يمكن حفظها كـ artifacts.

4. exit code واضح

إذا فشل الاختبار، يجب أن يفشل البناء.

هذا هو السلوك الذي يحول الاختبار إلى بوابة حقيقية:

apidog run ./tests.json
Enter fullscreen mode Exit fullscreen mode

إذا أعاد الأمر exit code غير صفري، يفشل الـ pipeline.

أدوات مثل Newman تشغّل مجموعات Postman من سطر الأوامر وتدعم تقارير CLI وJSON وJUnit. أدوات مثل Hurl مناسبة لفحوصات HTTP خفيفة يمكن وضعها في version control. أدوات مثل Prism وWireMock وMockoon تميل أكثر إلى mocking وstubbing. الاختيار يعتمد على مكان وجود العقود والاختبارات في فريقك.

أين يتناسب Apidog

Apidog CLI هو طريقة لتشغيل اختبارات API بدون واجهة رسومية. الأمر apidog run يستطيع تشغيل سيناريوهات الاختبار، أو مجلدات السيناريوهات، أو مجموعات الاختبار، أو الملفات المحلية المُصدّرة بدون فتح واجهة رسومية.

الاستخدام العملي يكون كالتالي:

apidog run ./tests.json
Enter fullscreen mode Exit fullscreen mode

مع تقرير HTML وCLI:

apidog run ./tests.json -r html,cli
Enter fullscreen mode Exit fullscreen mode

مع بيانات تكرار:

apidog run ./tests.json -d data.csv -n 20
Enter fullscreen mode Exit fullscreen mode

مع بيئة محددة:

apidog run ./tests.json -e staging
Enter fullscreen mode Exit fullscreen mode

ومع فرع مشروع:

apidog run ./tests.json --branch main
Enter fullscreen mode Exit fullscreen mode

القدرات الأساسية التي تحتاجها في تشغيل headless موجودة هنا:

  • اختبار مدفوع بالبيانات: استخدم -d أو --iteration-data مع CSV أو JSON، و-n لتحديد عدد التكرارات.
  • تقارير متعددة: استخدم -r لاختيار reporters مثل cli وhtml وjson.
  • بيئات وفروع: استخدم -e للبيئة و--branch للفرع.

الميزة المهمة هي الربط بين التصميم والتنفيذ. مع Apidog، الاختبارات التي تشغّلها headless تأتي من نفس العقد الذي صممته ووثقته وحاكيته. هذا يقلل احتمال وجود مجموعة اختبارات منفصلة تنحرف عن المواصفات.

يمكنك أيضًا تشغيل mock server من Apidog داخل CI لاختبار المستهلكين قبل أن تكون التبعية الحقيقية جاهزة. للحصول على مسار كامل من البداية إلى النهاية، راجع دليل Apidog CLI.

هناك جانب مرتبط بالذكاء الاصطناعي أيضًا. خادم MCP الخاص بـ Apidog يسمح لوكيل ذكاء اصطناعي أو IDE مثل Cursor أو Claude بقراءة مواصفات الـ API والعمل معها مباشرة. هذا مفيد عندما يساعد الوكيل في إنشاء أو صيانة اختبارات سيتم تشغيلها لاحقًا بدون واجهة رسومية. يشرح مقال تصحيح الأخطاء المرئي باستخدام عميل Apidog MCP كيف يعمل هذا الاتصال عمليًا.

مثال CI مبسط

يمكنك وضع تشغيل headless كمرحلة في pipeline. الفكرة العامة:

api_tests:
  script:
    - apidog run ./tests.json -e staging -r cli,json
Enter fullscreen mode Exit fullscreen mode

إذا فشل أي assertion داخل الاختبارات، يعيد الأمر exit code غير صفري، وبالتالي تفشل المرحلة.

نفس الفكرة تصلح مع GitHub Actions، GitLab CI، Jenkins، أو أي runner يستطيع تنفيذ أوامر shell.

الأسئلة المتكررة

هل اختبار الـ API بدون واجهة رسومية هو نفسه الاختبار الآلي؟

يتداخلان، لكنهما ليسا نفس الشيء تمامًا. الاختبار الآلي يعني أن الخطوات تعمل دون تدخل يدوي. اختبار الـ API بدون واجهة رسومية هو اختبار آلي لا يحتوي على GUI في مسار التنفيذ. معظم اختبارات API الآلية الحديثة تكون headless لأن تشغيلها من CLI هو الأنسب للـ CI/CD.

هل ما زلت بحاجة إلى أداة واجهة رسومية؟

نعم غالبًا، لكن لدور مختلف. استخدم الواجهة الرسومية لتصميم الطلب، وفحص الاستجابة، وتصحيح أول نسخة من الاختبار. بعد أن يصبح الاختبار مستقرًا، شغّله من CLI داخل pipeline. هذا هو النمط وراء اختبار Apidog CLI من سطر الأوامر.

كيف يتناسب الاختبار بدون واجهة رسومية مع CI/CD؟

أضف أمر التشغيل كمرحلة داخل الـ pipeline. إذا نجح الأمر، يستمر البناء أو النشر. إذا فشل وأعاد exit code غير صفري، يتوقف الـ pipeline. هذا هو الأساس العملي لتشغيل اختبارات الـ API في CI بدون خطوة يدوية.

هل يمكن اختبار واجهات API وهمية؟

نعم. يمكنك تشغيل الاختبارات ضد mock server أثناء بناء backend الحقيقي. هذا شائع في محاكاة واجهات الـ API، ويسمح للواجهة الأمامية أو الخدمات المستهلكة بالتحقق من العقد مبكرًا داخل CI.

خاتمة

اختبار الـ API بدون واجهة رسومية هو تشغيل اختباراتك بدون شاشة: مدفوع بالعقد، يعمل من الطرفية، يعيد مخرجات قابلة للقراءة آليًا، ومناسب للـ CI/CD. عندما يكون الـ API هو المنتج، فهذا النمط هو الطريقة العملية لحماية كل commit وmerge وdeploy.

إذا أردت تجربته، قم بتنزيل Apidog، صمّم أو استورد واجهة الـ API، ثم شغّل اختباراتك بدون واجهة رسومية باستخدام apidog run. نفس العقد الذي تصممه يمكن أن يدعم الاختبارات التي تحرس خط الأنابيب الخاص بك داخل Apidog.

Top comments (0)