يعتمد اختيار أداة تشغيل اختبارات واجهة سطر الأوامر (CLI) لخط أنابيبك على سؤال عملي: أين تعيش تعريفات واختبارات API لديك اليوم، وما الذي تريد تشغيله تلقائيًا في CI؟ إذا كان فريقك يبني الطلبات والاختبارات داخل Insomnia، فـ inso هو الخيار الطبيعي. إذا كنت تريد سير عمل موحدًا للتصميم، والمحاكاة، والتوثيق، والاختبار، فـ Apidog CLI يقدّم نموذجًا مختلفًا.
ما هي كل أداة؟
inso هو واجهة سطر الأوامر الخاصة بـ Insomnia، عميل API مفتوح المصدر من Kong. عمليًا، يستخدمه الفريق في CI من أجل:
- تشغيل مجموعات الطلبات.
- تشغيل مجموعات اختبار الوحدات.
- تدقيق مواصفات OpenAPI.
يقرأ inso من نفس بيانات تطبيق Insomnia، سواء من مجلد .insomnia المتزامن مع Git أو من بيانات تطبيق سطح المكتب.
Apidog CLI هو مشغّل الطرفية الخاص بـ Apidog، وهي منصة API تجمع التصميم، التصحيح، المحاكاة، التوثيق، والاختبار داخل مساحة عمل واحدة. من الطرفية يمكنك تشغيل سيناريوهات الاختبار والمجموعات، استخدام بيانات CSV/JSON، وإخراج تقارير بصيغ متعددة.
الفرق الأساسي: inso مشغّل اختبارات ومدقق OpenAPI داخل نظام Insomnia. أما Apidog CLI فهو واجهة أتمتة لمنصة API أوسع.
Apidog CLI مقابل inso: مقارنة سريعة
| القدرة | inso (واجهة سطر الأوامر لـ Insomnia) | Apidog CLI |
|---|---|---|
| التثبيت |
brew install inso، Docker (kong/inso)، أو تنزيل مباشر |
تنزيل المثبت؛ يشغل السيناريوهات من مشروع Apidog |
| ما يشغله | مجموعات الاختبار ومجموعات الطلبات، المشار إليها بالاسم | سيناريوهات الاختبار والمجموعات من مشروع |
| مصدر البيانات | مجلد .insomnia أو قاعدة بيانات تطبيق Insomnia؛ يمكن تجاوزها باستخدام --workingDir/--src
|
سيناريوهات اختبار المشروع متزامنة مع مساحة عمل Apidog |
| الاختبار القائم على البيانات | ليس علمًا مدمجًا | نعم، عبر -d مع CSV/JSON |
| التقارير | إخراج الاختبار إلى الطرفية/CI | CLI، HTML، JSON؛ وتقارير سحابية عبر --upload-report
|
| تدقيق المواصفات | نعم، inso lint spec عبر Spectral |
لا يوجد مدقق مستقل؛ يتحقق من صحة المواصفات عند الاستيراد |
| المورد/الفرع كتعليمات برمجية | لا | نعم، إدارة نقاط النهاية، المخططات، والفروع من CLI |
| تكامل المنصة | يتكامل مع عميل Insomnia | تصميم، محاكاة، توثيق، واختبار في منصة واحدة |
| مفتوح المصدر | نعم، Insomnia مفتوح المصدر | منصة تجارية |
| التسعير | مجاني | طبقة مجانية متاحة |
1. التثبيت في بيئة التطوير وCI
تثبيت inso
إذا كان CI لديك يدعم Homebrew:
brew install inso
أو استخدم Docker لتجنب إدارة الاعتمادات محليًا:
docker pull kong/inso:latest
هذا مناسب لمشغلات CI التي تريد فيها بيئة ثابتة وقابلة للتكرار.
تثبيت Apidog CLI
يُثبت Apidog CLI من صفحة تنزيل Apidog، ثم يشغّل السيناريوهات الموجودة داخل مشروع Apidog.
لإعداد كامل من البداية، راجع:
2. تشغيل الاختبارات: من أين تقرأ الأداة؟
هذا هو الفرق العملي الأهم في قرار Apidog CLI مقابل Insomnia CLI.
تشغيل اختبارات Insomnia باستخدام inso
يعتمد inso على الأسماء. تشير إلى مجموعة اختبار أو مجموعة طلبات باسمها:
inso run test "Smoke Suite" --env "CI"
inso run collection "User API" --env "Staging"
inso script seed-data --env env_staging
لكي يعمل هذا في CI، تأكد من الآتي:
- مجلد
.insomniaموجود داخل المستودع أو متاح في مسار معروف. - أسماء المجموعات ثابتة ولا تتغير عشوائيًا.
- البيئة المطلوبة موجودة، مثل
CIأوStaging.
يمكنك توجيه inso إلى مصدر بيانات محدد باستخدام:
inso run test "Smoke Suite" --env "CI" --workingDir ./path-to-project
أو باستخدام --src حسب طريقة تنظيم البيانات.
تشغيل سيناريوهات Apidog CLI
في Apidog CLI، تشغّل سيناريو أو مجموعة من مشروع Apidog:
apidog run -t "<scenario-or-collection>" -e "<environment>"
مثال:
apidog run -t "Smoke Suite" -e "CI"
النموذج هنا مختلف: الاختبار موجود داخل مشروع Apidog، وليس داخل مجلد .insomnia يجب الالتزام به في Git. هذا مفيد إذا كان فريقك يريد أن تكون الواجهة الرسومية، التوثيق، والاختبارات كلها متزامنة من نفس مساحة العمل.
3. الاختبار القائم على البيانات
إذا كان لديك سيناريو واحد وتريد تشغيله على عشرات الحالات، فهذه نقطة مهمة.
يدعم Apidog CLI التشغيل الموجه بالبيانات باستخدام -d مع CSV أو JSON:
apidog run -t "Checkout Flow" -e "Staging" -d ./datasets/orders.csv
مثال بسيط لملف CSV:
userId,productId,quantity
1001,sku-001,1
1002,sku-002,3
1003,sku-003,2
كل صف يصبح تكرارًا مستقلًا بقيمه الخاصة داخل السيناريو.
للتفاصيل حول ربط المتغيرات بالأعمدة، راجع الاختبار الموجه بالبيانات باستخدام Apidog CLI.
في المقابل، لا يوفر inso علمًا مدمجًا لتكرار التشغيل عبر CSV/JSON. يمكنك تنفيذ ذلك بكتابة سكربت حول inso داخل CI، لكن هذا ليس جزءًا مباشرًا من CLI.
4. التقارير: ماذا تحصل بعد التشغيل؟
في CI، لا يكفي أن تعرف أن الاختبار فشل. غالبًا تحتاج إلى تقرير يمكن مشاركته أو أرشفته كـ artifact.
تقارير Apidog CLI
يدعم Apidog CLI عدة صيغ:
apidog run -t "Smoke Suite" -e "CI" -r cli,html,json
يمكن استخدام:
-
CLIلقراءة سريعة داخل السجلات. -
HTMLكتقرير قابل للمشاركة. -
JSONللمعالجة الآلية أو الدمج مع لوحات مراقبة. -
--upload-reportلرفع التقرير والحصول على نسخة مستضافة.
مثال:
apidog run -t "Smoke Suite" -e "CI" -r html,json --upload-report
راجع دليل تقارير اختبار Apidog CLI لمعرفة الصيغ المتاحة وطريقة استخدامها.
تقارير inso
يعرض inso نتائج التشغيل في الطرفية ويعتمد CI على رمز الخروج لتحديد النجاح أو الفشل. هذا كافٍ للحالات الأساسية:
inso run test "Smoke Suite" --env "CI"
إذا فشل اختبار، يفشل الأمر، وبالتالي يمكن إيقاف البناء.
5. تدقيق OpenAPI: أين يتفوق inso؟
هذه نقطة قوة واضحة لـ inso.
يوفر inso أمرًا مباشرًا لتدقيق مواصفات OpenAPI:
inso lint spec "Payments API"
ويستخدم Spectral، وهو مدقق معروف لمواصفات OpenAPI. هذا يعني أنه يمكنك فرض قواعد جودة المواصفات داخل CI.
مثال:
inso lint spec "Payments API"
inso export spec "Payments API" --output openapi.yaml
إذا كان فريقك يعمل بأسلوب API-first ويريد منع الدمج عند مخالفة قواعد OpenAPI، فـ inso مناسب جدًا لهذا الجزء.
أما Apidog CLI فلا يحتوي على مدقق OpenAPI مستقل أو أمر lint بديل لـ Spectral. يتحقق Apidog من صحة المواصفات عند الاستيراد، لكنه لا يستبدل خطوة Spectral داخل CI. إذا كان linting مطلبًا صارمًا، استخدم inso أو أضف Spectral كخطوة مستقلة.
6. إدارة الموارد والفروع كتعليمات برمجية
يمتلك Apidog CLI جانبًا لا يقدمه inso: إدارة موارد API من الطرفية.
يمكن استخدامه مع موارد مثل:
- نقاط النهاية.
- المخططات.
- البيئات.
- الفروع.
- طلبات الدمج.
الفائدة العملية هنا أنك تستطيع ربط تغييرات تعريف API مع نفس الأتمتة التي تشغل الاختبارات.
أما inso فيبقى في نطاقه الأساسي: تشغيل مجموعات Insomnia وتدقيق/تصدير المواصفات. لا يعمل كواجهة إدارة موارد لتعديل نقاط النهاية أو إدارة الفروع داخل منصة API.
7. التكامل مع المنصة والتسعير
inso جزء من نظام Insomnia. Insomnia مفتوح المصدر، وهذا مهم للفرق التي تفضل الأدوات القابلة للفحص أو التي تعتمد على نظام مفتوح. كذلك، inso مجاني ويقدّم تشغيلًا جيدًا للاختبارات مع تدقيق Spectral مدمج.
تجدر الإشارة أيضًا إلى أن Insomnia 8 قدم في 2023 حسابًا سحابيًا/تسجيل دخول إلزاميًا، وظهرت ردود فعل حول الترحيل وفقدان البيانات في تلك الفترة. إذا كان هذا جزءًا من تقييمك، راجع:
Apidog منصة تجارية مع طبقة مجانية. الفكرة الأساسية هي تقليل عدد الأدوات المنفصلة: التصميم، المحاكاة، التوثيق، التصحيح، والاختبار داخل مساحة عمل واحدة، وCLI هو طبقة الأتمتة لهذه المساحة.
للمقارنة الأوسع، راجع:
- Apidog مقابل Insomnia
- Insomnia مقابل Apidog
- كيفية استخدام Insomnia لاختبار API
- اختبار REST API من سطر الأوامر
8. مثال CI مختصر
الفكرة في الأداتين واحدة:
- ثبّت CLI.
- جهّز مصدر الاختبارات أو المصادقة.
- شغّل الاختبارات.
- اترك رمز الخروج يحدد نجاح أو فشل البناء.
مثال مبسط:
# inso in CI
- run: brew install inso
- run: inso run test "Smoke Suite" --env "CI"
# Apidog CLI in CI
- run: apidog run -t "Smoke Suite" -e "CI" -r html,json
إذا كنت تريد إعدادًا عمليًا لـ Apidog داخل CI/CD، راجع:
الخلاصة: أيهما تختار؟
اختر inso إذا كان فريقك:
- يستخدم Insomnia بالفعل.
- يلتزم بمجلد
.insomniaداخل Git. - يحتاج إلى
inso lint specلتدقيق OpenAPI عبر Spectral. - يريد أداة مجانية ومباشرة لتشغيل مجموعات Insomnia في CI.
اختر Apidog CLI إذا كان فريقك:
- يريد منصة موحدة للتصميم، المحاكاة، التوثيق، والاختبار.
- يحتاج إلى اختبار قائم على البيانات عبر
-d. - يريد تقارير HTML/JSON وتقارير مستضافة.
- يريد إدارة موارد API والفروع من CLI.
- يفضل أن تكون السيناريوهات في مشروع API مشترك بدل مجلد محلي متزامن.
إذا كنت تنتقل من inso، راجع الترحيل من inso إلى Apidog CLI.
للتجربة العملية، قم بتنزيل Apidog وشغّل سيناريو اختبار على واجهة API حقيقية.
Top comments (0)