Apidog CLI مقابل Postman CLI: مشغل اختبارات CI الأفضل

تنجح اختبارات واجهة برمجة التطبيقات (API) الخاصة بك عندما تنقر على "تشغيل" على جهاز الكمبيوتر المحمول الخاص بك. هذا لا يثبت شيئًا. الاختبار الذي يهم هو الذي يتم تشغيله مع كل طلب سحب، وكل عملية دمج، وكل بناء ليلي، دون وجود أي إنسان للنقر على أي شيء. تقع مهمة إدخال اختباراتك في هذه الحلقة على عاتق برنامج تشغيل سطر الأوامر (CLI runner). إنه يأخذ الاختبارات التي كتبتها بالفعل، ويقوم بتشغيلها بدون واجهة رسومية داخل مسار عملك (pipeline)، ويخرج برمز حالة يمكن أن يقرأه نظام التكامل المستمر (CI) الخاص بك، ويكتب تقريرًا يظهر على لوحة معلومات البناء.

يبرز برنامجان لتشغيل الاختبارات مرارًا وتكرارًا عندما تقوم الفرق بإعداد هذا: سطر الأوامر الخاص بـ Postman (Postman CLI) وسطر الأوامر الخاص بـ Apidog (Apidog CLI). كلاهما يستهدف نفس الهدف من نقاط بداية مختلفة. يقوم Postman CLI بتشغيل المجموعات التي تنشئها في Postman. ويقوم Apidog CLI بتشغيل سيناريوهات الاختبار المرئية التي تنشئها في Apidog. يتم تثبيت كلاهما في خطوة واحدة، ويتكامل كلاهما مع GitHub Actions و GitLab CI و Jenkins، وكلاهما يحول البناء إلى اللون الأحمر عند فشل الاختبار. تكمن الاختلافات الحقيقية قبل أمر التشغيل: كيفية تأليف الاختبارات، وكيفية المصادقة في نظام التكامل المستمر (CI)، ومكان وجود تعريف الاختبار فعليًا.

💡

هذه مقارنة على مستوى الأوامر بين الاثنين. لا توجد مغالطات. يقوم Postman CLI بالعديد من الأشياء بشكل جيد، وسترى بالضبط أين يتناسب كل برنامج تشغيل قبل الالتزام بواحد في مسار عملك (pipeline). إذا كنت جديدًا على Apidog، فهو منصة API شاملة تغطي التصميم والتصحيح والاختبار والمحاكاة والتوثيق في مساحة عمل واحدة، وسطر الأوامر هو الجزء الذي ينقل اختباراتك إلى الأتمتة.

زر

ملخص سريع (TL;DR)

Postman CLI (الملف التنفيذي postman) يقوم بتشغيل المجموعات المخزنة في مساحة عمل Postman الخاصة بك. يعتمد على Newman، وهو موقع ومدعوم من Postman، ويصادق باستخدام مفتاح API الخاص بـ Postman. عندما تكون مسجل الدخول، فإنه يرسل نتائج التشغيل إلى سحابة Postman تلقائيًا.
Apidog CLI (apidog-cli، الملف التنفيذي apidog) يقوم بتشغيل سيناريوهات الاختبار التي تصممها بصريًا في Apidog. توجهه إلى سيناريو معين باستخدام المعرف (ID) ورمز الوصول، ويقوم بتنفيذ هذا السيناريو بدون واجهة رسومية.
كلاهما يصدر تقارير بصيغ JUnit و JSON و HTML وتقارير طرفية. وكلاهما يتسبب في فشل عملية البناء عند فشل الاختبار. ملف JUnit XML هو ما يتصل بلوحة معلومات التكامل المستمر (CI dashboard) في كلتا الحالتين.
اختر Postman CLI عندما تكون اختباراتك موجودة بالفعل في مجموعات Postman ويلتزم فريقك بسحابة Postman لإعداد التقارير والسجل.
اختر Apidog CLI عندما تريد تأليف سيناريوهات مرئية، وتسلسل الطلبات، وإدارة البيئات، وعمليات تشغيل مدفوعة بالبيانات من مصدر واحد للحقيقة، مع تحكم كامل فيما إذا كانت التقارير تبقى محلية أو تنتقل إلى السحابة.

المشكلة الحقيقية: اختبارات موجودة ولكن لا تُشغل أبدًا

الاختبار الذي تقوم بتشغيله يدويًا هو اختبار يتلف. كتبه شخص ما، ونجح مرة واحدة، ثم ظل دون تغيير بينما تدهورت واجهة برمجة التطبيقات (API) تحت وطأته. بعد ثلاثة أشهر، يصبح الاختبار خاطئًا ولم يلاحظ أحد، لأنه لم يقم أحد بتشغيله. الحل ليس في كتابة المزيد من الاختبارات. بل هو جعل الاختبارات التي لديك تعمل تلقائيًا مع كل تغيير، مع إشارة نجاح أو فشل يمكن لمسار العمل (pipeline) أن يتصرف بناءً عليها.

برنامج تشغيل سطر الأوامر (CLI runner) هو الأداة التي تسد هذه الفجوة. لكسب مكان في نظام التكامل المستمر (CI)، يجب أن يقوم بثلاثة أشياء. يجب أن يعمل بدون واجهة رسومية (GUI)، لأن برنامج تشغيل CI الخاص بك لا يحتوي على شاشة. يجب أن يخرج بقيمة غير صفرية عندما يفشل شيء ما، حتى يتحول البناء إلى اللون الأحمر ويتم حظر دمج خاطئ. ويجب أن يكتب تقريرًا يمكن قراءته آليًا، بحيث يرى المراجع ما الذي تعطل دون إعادة تشغيل أي شيء محليًا. كل من Postman CLI و Apidog CLI يجتازان هذا المعيار بنظافة. يختلفان في كل ما يحدث قبل أمر run: كيف تم كتابة الاختبار، وأين يقيم عندما يبحث عنه CI.

إذا كنت تقوم بإعداد الاختبارات الآلية من الصفر، فإن الأنماط الأوسع في أتمتة اختبارات API في CI/CD تستحق القراءة جنبًا إلى جنب مع هذه المقالة. هنا، ينصب التركيز على برنامجي التشغيل.

ما يميز Postman CLI

أولاً، نقطة توضيح تربك الكثير من الناس: Postman CLI ليس هو Newman. نيومان (Newman) هو برنامج التشغيل الأقدم، مفتوح المصدر، المعتمد على npm الذي استخدمه المجتمع لسنوات. Postman CLI هو أداة أحدث، مبنية على أساس Newman، ولكنه موقع ومدعوم رسميًا من قبل شركة Postman. إذا كنت تستخدم Newman، فإن الاثنين غير قابلين للتبديل، ويكمن الاختلاف في نظام التكامل المستمر (CI). لقد كتبنا عن هذا التمييز الدقيق في Postman CLI مقابل Newman إذا كنت تختار بين الخيارين من جانب Postman.

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

تثبيته هو أمر واحد. على نظامي التشغيل macOS و Linux، تقوم بتشغيل برنامج التثبيت الرسمي:

curl -o- "https://dl-cli.pstmn.io/install/unix.sh" | sh

على Windows، تستخدم مثبت PowerShell الموقع، وهناك أيضًا حزمة npm إذا كنت تفضل تثبيتها كاعتماد تطويري:

npm install -g postman-cli

الملف التنفيذي هو postman. في CI، تقوم بالمصادقة باستخدام مفتاح API الخاص بـ Postman، وهي الطريقة التي يوصي بها Postman لمسارات العمل (pipelines):

postman login --with-api-key $POSTMAN_API_KEY

ثم تقوم بتشغيل مجموعة عن طريق معرفها (ID)، أو عن طريق مسار ملف محلي إذا كنت قد قمت بتصديرها:

postman collection run $POSTMAN_COLLECTION_ID -e $POSTMAN_ENV_ID

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

ما يميز Apidog CLI

يتخذ Apidog مسارًا مختلفًا لنفس مسار العمل (pipeline). يمكنك بناء الاختبارات بصريًا داخل تطبيق Apidog: ربط عدة طلبات في سيناريو اختبار واحد، إضافة تأكيدات (assertions) على كل استجابة، سحب قيمة من استجابة واحدة وتغذيتها للطلب التالي، وتكرار السيناريو بأكمله عبر ملف بيانات. يعتبر CLI المنفذ بدون واجهة رسومية لهذه السيناريوهات. لا يحتوي على تنسيق اختبار خاص به. يصل إلى مشروع Apidog الخاص بك، ويجد السيناريو الذي تحدده بالمعرف (ID)، ويشغله تمامًا كما يفعل التطبيق، ثم يقدم التقارير.

النتائج الإيجابية هي أنه لا أحد يحتفظ بنسختين من نفس الاختبار. السيناريو الذي بنيته في المحرر المرئي هو الاختبار الذي يعمل في CI. لا توجد خطوة حيث تعيد صياغة اختبار يعمل كبرنامج نصي ثم تقوم بتصحيح البرنامج النصي. حلقة التأليف السريع وحلقة الأتمتة تشتركان في مصدر واحد للحقيقة. بالنسبة للتدفقات متعددة الخطوات، تسجيل الدخول ثم الإنشاء ثم القراءة ثم الحذف، يوفر هذا التسلسل المرئي الكثير من التعليمات البرمجية الوسيطة التي كنت ستكتبها يدويًا بخلاف ذلك. تتم تغطية آليات بناء هذه التدفقات في دليل سيناريوهات الاختبار لأتمتة اختبارات API.

التثبيت هو أمر npm واحد:

npm install -g apidog-cli

الملف التنفيذي هو apidog. يقوم التشغيل النموذجي بتسمية سيناريو بالمعرف (ID)، واختيار بيئة، وتعيين عدد التكرارات، والمصادقة باستخدام رمز وصول:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -n 1 -r html,junit

لا تكتب هذه المعرفات يدويًا. افتح سيناريو الاختبار في Apidog، انتقل إلى علامة التبويب CI/CD الخاصة به، انقر لإنشاء رمز وصول، ويقوم Apidog ببناء الأمر الكامل لك مع معرف السيناريو ومعرف البيئة المعبأين بالفعل. تقوم بنسخه مرة واحدة، ونقل الرمز المميز إلى سر CI، والإشارة إليه باسم $APIDOG_ACCESS_TOKEN في سير عملك.

نموذج الرمز المميز والمعرف هو أوضح فصل عن Postman CLI. يشغل Apidog الاختبارات المخزنة في مشروع يقوم CLI بجلبها عبر الشبكة، مصادقًا عليها بواسطة الرمز المميز. لا يوجد خيار سحابة منفصل للتقارير أيضًا: يمكنك اختيار --out-dir للتحف المحلية وإضافة --upload-report فقط عندما تريد دفع نظرة عامة إلى سحابة Apidog. تبقى التقارير حيث تضعها.

مقارنة جنبًا إلى جنب

المعيار	Postman CLI (`postman`)	Apidog CLI (`apidog`)
الحزمة / التثبيت	نص برمجي للتثبيت، مثبت موقع، أو `npm i -g postman-cli`	`npm i -g apidog-cli`
أمر التشغيل	`postman collection run <id\|file>`	`apidog run -t <scenarioId>`
مصدر الاختبار	المجموعات في مساحة عمل Postman الخاصة بك (أو ملف تم تصديره)	سيناريوهات الاختبار في مشروع Apidog الخاص بك، يتم جلبها بواسطة المعرف (ID)
التأليف	محرر المجموعات وتطبيق Postman	منشئ السيناريوهات المرئي في تطبيق Apidog
المصادقة في CI	مفتاح Postman API (`postman login --with-api-key`)	رمز الوصول (`--access-token`)
تحديد ما يتم تشغيله	معرف المجموعة (Collection ID) أو مسار الملف	سيناريو `-t`، مجلد `-f`، `--test-suite`
البيئة	`-e, --environment`	`-e, --environment <environmentId>`
المدفوعة بالبيانات	`-d, --iteration-data` (JSON أو CSV)	`-d, --iteration-data` (JSON أو CSV)
التكرارات	`-n, --iteration-count`	`-n, --iteration-count`
المبلغون (Reporters)	`cli`، `json`، `junit`، `html`	`cli`، `html`، `json`، `junit`
الفشل السريع	`--bail`	`--on-error end` (يتوقف افتراضيًا عند أول فشل)
التقارير السحابية	يرسل النتائج تلقائيًا عند تسجيل الدخول	يمكن تفعيله عبر `--upload-report`
مبني على	Newman	محرك Apidog الخاص

يبرز أمران من هذا الجدول. أولاً، يغطي كلا برنامجي التشغيل أساسيات CI بنفس الشكل تقريبًا: اختيار البيئة، والتكرار المعتمد على البيانات، وتنسيقات التقارير الأربعة المهمة، والخروج بقيمة غير صفرية عند الفشل. إذا كان كل ما تحتاجه هو برنامج تشغيل يتحول إلى اللون الأحمر عند دمج سيء، فإن أيًا منهما يقوم بالمهمة. ثانيًا، الانقسام الحقيقي يدور حول مكان وجود الاختبار وكيف كتبته. يشغل Postman CLI مجموعة موجودة في مساحة عمل Postman الخاصة بك. بينما يشغل Apidog CLI سيناريو مرئيًا موجودًا في مشروع Apidog الخاص بك.

المبلغون ورموز الخروج: الأجزاء التي يقرأها CI فعليًا

يثبت برنامج التشغيل قيمته في مسار عمل (pipeline) من خلال سلوكين: التقرير الذي يكتبه، ورمز الخروج الذي يعيده. إذا قمت بإعداد هذين الأمرين بشكل صحيح، فإن كل شيء آخر هو مجرد توصيلات.

يأخذ Postman CLI قائمة بالمبلغين مفصولة بفاصلات، وعند تسجيل دخولك، فإنه يرسل النتائج أيضًا إلى سحابة Postman:

postman collection run $POSTMAN_COLLECTION_ID \
  -e $POSTMAN_ENV_ID \
  --reporters cli,junit \
  --bail

المبلغ junit هو الذي تقوم لوحة معلومات CI الخاصة بك بتحليله إلى شجرة نجاح أو فشل. تتسبب علامة --bail في إيقاف التشغيل عند أول طلب أو اختبار أو تأكيد فاشل، مما يحافظ على سرعة التغذية الراجعة في اختبار الدخان (smoke test). إذا أسقطت --bail فإنه يشغل كل شيء، ثم يبلغ عن جميع الإخفاقات معًا. يخرج CLI بقيمة غير صفرية عند أي فشل، لذلك يتحول البناء إلى اللون الأحمر تلقائيًا.

يستخدم Apidog CLI نفس فكرة المبلغ -r ويكتب كل شيء تحت دليل إخراج واحد:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 \
  -r html,junit --out-dir ./apidog-reports

تحدد علامة --on-error الخاصة به سلوك منتصف السيناريو: end يتوقف عند الفشل الأول وهو الافتراضي، continue يشغل كل خطوة حتى تجمع جميع الإخفاقات في تقرير واحد، و ignore يتجاوز خطوة معروفة بعدم استقرارها دون تعطيل التشغيل. في كلتا الحالتين تنتهي العملية بقيمة غير صفرية إذا فشل أي شيء، ويهبط ملف JUnit XML في ./apidog-reports جاهزًا لالتقاطه من قبل لوحة معلوماتك.

الخلاصة العملية: كلاهما يكتب ملف JUnit XML، وكلاهما يفشل البناء بشكل صحيح، وكلاهما يقوم بأرشفة تقرير HTML يمكنك فتحه لاحقًا. الفرق في إعداد التقارير هو الرحلة ذهابًا وإيابًا إلى السحابة. يقوم Postman بدفع النتائج إلى سحابته افتراضيًا عند المصادقة. بينما يحتفظ Apidog بالتقارير محليًا ما لم تطلب منه التحميل. لا يوجد أحدهما أفضل من الآخر بشكل مطلق؛ أحدهما يناسب الفرق التي تريد سجلًا مستضافًا دون التفكير في الأمر، والآخر يناسب الفرق التي تريد تحديد ما الذي يغادر برنامج التشغيل بالضبط.

ربط كل منهما بـ GitHub Actions

شكل مهمة GitHub Actions هو نفسه لكلاهما: سحب المستودع (repo)، إعداد Node، تثبيت CLI، تشغيل الاختبارات، ويحظر رمز الخروج الفاشل الدمج. قم بتخزين السر في إعدادات المستودع الخاص بك، ولا تضعه أبدًا في ملف سير العمل.

إليك إصدار Postman CLI:

- name: Run API tests (Postman CLI)
  run: |
    curl -o- "https://dl-cli.pstmn.io/install/unix.sh" | sh
    postman login --with-api-key ${{ secrets.POSTMAN_API_KEY }}
    postman collection run $POSTMAN_COLLECTION_ID -e $POSTMAN_ENV_ID --reporters cli,junit --bail

وإصدار Apidog CLI:

- name: Run API tests (Apidog CLI)
  run: |
    npm install -g apidog-cli
    apidog run --access-token ${{ secrets.APIDOG_ACCESS_TOKEN }} -t 605067 -e 1629989 -r cli,junit

كلاهما قصير، وكلاهما قابل للقراءة، وكلاهما يتصرف بنفس الطريقة على المستوى الذي يهتم به مسار عملك (pipeline): التشغيل الناجح يخرج بقيمة صفر ويستمر الدمج، والتشغيل الفاشل يخرج بقيمة غير صفرية ويتم حظر الدمج. إذا كنت تريد شرحًا أعمق لتشغيل اختبارات API في سير عمل GitHub، فإن أتمتة اختبارات API باستخدام GitHub Actions يشرح ذلك خطوة بخطوة. بالنسبة لمستخدمي Jenkins، يتم توضيح نفس الفكرة في دمج اختبارات Apidog الآلية مع Jenkins.

إذًا، من يفوز في CI؟

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

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

يفوز Postman CLI عندما يكون فريقك بالفعل داخل Postman. مجموعاتك موجودة هناك، بيئاتك موجودة هناك، وتريد سجل تشغيل في سحابة Postman دون إعداد أي شيء. الرحلة السحابية ذهابًا وإيابًا في كل تشغيل هي راحة حقيقية لهذا الإعداد، والأداة موقعة ومدعومة رسميًا. إذا كان هذا يصف فريقك، فإن تبديل برامج التشغيل لن يضيف لك الكثير.

إذا كنت تشعر بالفعل بالتقييد بنموذج سحابة Postman، أو كنت ترغب فقط في تأليف الاختبارات مرة واحدة وتشغيلها في كل مكان، فإن الخطوة واضحة. قم بتنزيل Apidog، قم ببناء سيناريو، افتح علامة التبويب CI/CD الخاصة به، وانسخ أمر apidog run الذي تم إنشاؤه إلى مسار عملك (pipeline). هذا هو الإعداد بأكمله.

زر

الأسئلة الشائعة

هل Postman CLI هو نفسه Newman؟ لا. نيومان (Newman) هو برنامج تشغيل npm الأقدم مفتوح المصدر. Postman CLI هو أداة أحدث مبنية على أساس Newman، موقّعة ومدعومة من Postman، مع تقارير مدمجة إلى سحابة Postman. إذا كنت تختار بين الاثنين من جانب Postman، فإن Postman CLI مقابل Newman يوضح الاختلافات.

هل أحتاج إلى حساب أو رمز وصول لأي من واجهتي سطر الأوامر (CLI) في CI؟ نعم لكلاهما، ولكن الشكل يختلف. يصادق Postman CLI باستخدام مفتاح Postman API عبر postman login --with-api-key. يصادق Apidog CLI باستخدام رمز وصول يتم تمريره كـ --access-token. قم بتخزين أي منهما كسر CI، ولا تضعه أبدًا في ملف سير العمل.

هل يفشل كلا برنامجي التشغيل (runners) عملية البناء عند فشل الاختبار؟ نعم. يخرج كلاهما برمز حالة غير صفري عند أي اختبار أو تأكيد فاشل، وهذا ما يخبر نظام CI الخاص بك بوضع علامة حمراء على البناء وحظر الدمج. يستخدم Postman CLI الخيار --bail للتوقف عند أول فشل؛ بينما يستخدم Apidog CLI الخيار --on-error end، وهو الخيار الافتراضي له.

هل يمكنني الاحتفاظ بتقاريري محلية بدلاً من إرسالها إلى السحابة؟ يحتفظ Apidog CLI بالتقارير محلية افتراضيًا ويكتبها إلى --out-dir؛ تقوم بالتحميل فقط باستخدام --upload-report. يكتب Postman CLI تقارير محلية أيضًا، ولكن عند تسجيل دخولك، فإنه يرسل نتائج التشغيل أيضًا إلى سحابة Postman تلقائيًا.

كيف أحصل على أمر تشغيل Apidog الدقيق لسيناريو الخاص بي؟ افتح سيناريو الاختبار في Apidog، انتقل إلى علامة التبويب CI/CD الخاصة به، قم بإنشاء رمز وصول، ويقوم Apidog ببناء أمر apidog run الكامل مع معرف السيناريو ومعرف البيئة المعبأين بالفعل. انسخه، انقل الرمز المميز إلى سر CI، وهكذا تكون قد انتهيت. للحصول على كل علامة متاحة، قم بتشغيل apidog run --help.

أي واحد يجب أن يختاره فريق ينتقل من سحابة Postman؟ إذا كان السبب الذي يجعلك تغادر هو نموذج السحابة المركزي أو التسعير، فإن Apidog CLI يناسبك، لأنه يشغل سيناريو مرئيًا واحدًا من مشروعك ويسمح لك بتحديد ما الذي يغادر برنامج التشغيل. ابدأ بمقارنة Apidog مقابل Postman لمعرفة كيفية توافق المنصتين فيما وراء برنامج التشغيل.