كيفية تشغيل اختبارات API باستخدام Apidog CLI؟

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

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

باختصار

• Apidog CLI هو حزمة npm تسمى apidog-cli. قم بتثبيتها عالميًا باستخدام npm install -g apidog-cli، ثم قم بتشغيل السيناريوهات باستخدام الأمر apidog run.
• يقوم بتشغيل سيناريوهات الاختبار التي تصممها في Apidog. لا تعيد كتابة الاختبارات كرمز؛ تنفذ CLI نفس السيناريو بواسطة المعرّف (ID)، باستخدام رمز وصول للمصادقة.
• التشغيل الأساسي: apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenarioId> -e <environmentId> -n 1 -r html,cli.
• تغطي التقارير cli وhtml وjson وjunit. JUnit XML هو ما يوصل مباشرة بلوحات معلومات اختبار CI.
• رمز الخروج غير الصفري عند فشل الاختبار هو ما يجعل CLI بوابة جودة حقيقية. الاختبارات الفاشلة تفشل عملية البناء افتراضيًا.
• يعمل في أي مشغل CI يحتوي على Node.js: GitHub Actions وGitLab CI وJenkins وCircleCI وAzure Pipelines والمزيد.

ما هو Apidog CLI بالضبط

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

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

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

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

المتطلبات الأساسية

قبل تشغيل أمر واحد، تحتاج إلى ثلاثة أشياء:

1. Node.js v16 أو أحدث. يتم شحن CLI كحزمة npm، لذا فإن وقت تشغيل Node هو التبعية الوحيدة للنظام. تحقق من إصدارك باستخدام node -v. أي صورة CI تحتوي على Node 16+ مؤهلة بالفعل.
2. سيناريو اختبار Apidog. تُشغّل CLI السيناريوهات، وليس الطلبات الفردية. قم ببناء سيناريو في تطبيق Apidog أولاً: اربط طلباتك، أضف تأكيدات، قم بإعداد أي تكرار يعتمد على البيانات تحتاجه. إذا كنت جديدًا في تأليف التأكيدات، فإن تأكيدات API: دليل عملي يوضح كيفية التحقق من الاستجابات.
3. رمز وصول. هذا يصدق CLI على حساب Apidog الخاص بك حتى يتمكن من جلب وتشغيل السيناريو. تقوم بإنشائه داخل علامة تبويب CI/CD الخاصة بسيناريو الاختبار؛ المزيد عن ذلك أدناه.

هذا كل شيء. لا يوجد تثبيت Apidog منفصل على صندوق CI، لا واجهة رسومية، لا ملف ترخيص. الحزمة والرمز كافيان.

تثبيت Apidog CLI

قم بتثبيته عالميًا باستخدام npm:

npm install -g apidog-cli

ثم تأكد من أن كل شيء تم حله بشكل صحيح:

node -v && apidog -v && which node && which npm && which apidog

إذا طبع هذا أرقام الإصدارات والمسارات، فقد انتهيت. الثنائي هو apidog، لذا يبدأ كل أمر بـ apidog run.

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

npm install -g apidog-cli
apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -r cli

والثاني هو تشغيله بدون تثبيت عام دائم عبر npx، مما يتجنب تغيير الحزم العالمية للمشغل:

npx apidog-cli run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -r cli

كلاهما يعمل. نهج npx أنظف لمشغلي CI الزائلين؛ التثبيت العام أسرع قليلاً عندما تقوم بتخزينه مؤقتًا بين عمليات التشغيل.

الحصول على رمز الوصول ومعرف السيناريو الخاص بك

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

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

هذا الأمر المُنشأ هو نقطة البداية الأساسية. يبدو هكذا:

apidog run --access-token YOUR_ACCESS_TOKEN -t 605067 -e 1629989 -n 1 -r html,cli

الأرقام هي معرفات حقيقية من مشروعك. 605067 هو معرف سيناريو الاختبار. 1629989 هو معرف البيئة. لن تكتب هذه الأرقام يدويًا أبدًا تقريبًا؛ ستقوم بنسخها من علامة تبويب CI/CD مرة واحدة ثم تقوم بتعيين الرمز كمعامل.

قاعدة واحدة تستحق الذكر مبكرًا: تعامل مع رمز الوصول ككلمة مرور. لا تلصقه في ملف تكوين ملتزم أو تعريف مسار عام. قم بتخزينه كسر في نظام CI الخاص بك وارجع إليه كمتغير بيئة. يستخدم كل مثال أدناه $APIDOG_ACCESS_TOKEN لهذا السبب بالضبط.

أمر apidog run، علامة تلو الأخرى

تدور واجهة سطر الأوامر (CLI) بالكامل حول أمر واحد. إليك سطح الخيارات الكامل، مجمعة حسب ما تتحكم فيه كل مجموعة.

اختيار ما يجب تشغيله

يمكنك اختيار واحدة من -t أو -f أو --test-suite حسب النطاق. سيناريو واحد لاختبار دخان مركز، أو مجلد لمنطقة ميزة، أو مجموعة اختبار عندما تريد تشغيل مجموعة منسقة من السيناريوهات معًا كوظيفة منطقية واحدة.

المصادقة

هذه هي العلامة الوحيدة التي يحتاجها كل أمر CI. مررها من سر، وليس أبدًا مباشرة.

البيئة والتكرار

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

التقارير

هذا هو المكان الذي يكتسب فيه CLI مكانته في خط الأنابيب. قم بتمرير تنسيقات متعددة في وقت واحد، مفصولة بفواصل:

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

يمنحك cli مخرجًا طرفيًا قابلاً للقراءة للبشر الذين يقرؤون سجل البناء. ينتج html تقريرًا مستقلاً يمكنك أرشفته كجزء بناء وفتحه في متصفح. يصدر junit ملف XML بتنسيق JUnit القياسي، والذي تعرفه جميع لوحات معلومات CI تقريبًا كيفية تحليله إلى شجرة نجاح/فشل. يمنحك json النتيجة المنظمة الخام إذا كنت تريد معالجتها لاحقًا.

معالجة الأخطاء وسلوك الخروج

تتحكم --on-error فيما يحدث في منتصف السيناريو. توقف end التشغيل عند أول فشل، وهو ما تريده عادةً لاختبار دخان سريع الفشل. تشغل continue كل خطوة حتى ترى جميع الإخفاقات في تقرير واحد. ignore هي للحالات النادرة حيث تكون الخطوة غير مستقرة معروفة ولا تريد أن تعرقل التشغيل.

TLS والشهادات

استخدم هذه الخيارات عند اختبار نقاط النهاية التي تعتمد على TLS المتبادل أو سلاسل CA الداخلية. استخدم -k فقط كحل أخير على المضيفين الداخليين الموثوق بهم حيث تكون الشهادة موقعة ذاتيًا؛ ولا تستخدمها أبدًا ضد أي شيء عام.

الناتج والتشخيص

--verbose هي خطوتك الأولى عندما ينجح الاختبار محليًا ولكنه يفشل في CI؛ فإنه يوضح لك الطلب الدقيق الذي أرسله المشغل والاستجابة الدقيقة التي تلقاها. --silent مخصصة للوظائف الليلية الصاخبة حيث تهتم فقط برمز الخروج والتقرير المحفوظ.

رموز الخروج: الجزء الذي يجعل CI يعمل

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

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

يمكنك تشكيل هذا باستخدام --on-error. السلوك الافتراضي يفشل عند أول تأكيد مكسور، مما يحافظ على سرعة التغذية الراجعة. انتقل إلى --on-error continue عندما تفضل رؤية كل الإخفاقات في تقرير واحد قبل أن يصبح البناء أحمر. في كلتا الحالتين، لا يزال التشغيل ينتهي بخروج غير صفري إذا فشل أي شيء، لذلك تظل البوابة قائمة.

التشغيل في GitHub Actions

سير عمل كامل يشغل سيناريو Apidog في كل طلب سحب وينشر التقرير كقطعة أثرية.

name: API tests

on:
 pull_request:
 branches: [main]

jobs:
 api-tests:
 runs-on: ubuntu-latest
 steps:
 - name: Checkout
 uses: actions/checkout@v4

 - name: Set up Node.js
 uses: actions/setup-node@v4
 with:
 node-version: '20'

 - name: Install Apidog CLI
 run: npm install -g apidog-cli

 - name: Run API test scenario
 run: |
 apidog run \
 --access-token "$APIDOG_ACCESS_TOKEN" \
 -t 605067 \
 -e 1629989 \
 -n 1 \
 -r html,junit \
 --out-dir ./apidog-reports
 env:
 APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

 - name: Upload report
 if: always()
 uses: actions/upload-artifact@v4
 with:
 name: apidog-report
 path: ./apidog-reports

يعيش الرمز المميز في أسرار المستودع ويصل إلى الخطوة كمتغير بيئة. تشير if: always() في خطوة التحميل إلى أنك لا تزال تحصل على التقرير حتى عند فشل الاختبارات، وهذا هو بالضبط الوقت الذي تريد قراءته فيه. إذا تعطل اختبار، فإن خطوة apidog run تخرج برمز غير صفري، وتصبح المهمة حمراء، ويعرض طلب السحب فحصًا فاشلاً.

التشغيل في GitLab CI

نفس النمط في .gitlab-ci.yml:

stages:
 - test

api-tests:
 stage: test
 image: node:20
 script:
 - npm install -g apidog-cli
 - >
 apidog run
 --access-token "$APIDOG_ACCESS_TOKEN"
 -t 605067
 -e 1629989
 -r junit,cli
 --out-dir ./apidog-reports
 artifacts:
 when: always
 paths:
 - apidog-reports/
 reports:
 junit: apidog-reports/*.xml

نقطتان يجب ملاحظتهما. قم بتخزين APIDOG_ACCESS_TOKEN كمتغير CI/CD محمي ومخفي ضمن الإعدادات، وليس في الملف. ويخبر جزء reports: junit: برنامج GitLab بتحليل ملف JUnit XML وعرض النتائج في ويدجت طلب الدمج، بحيث يرى المراجع التأكيدات التي فشلت دون تنزيل أي شيء.

التشغيل في Jenkins

في مسار عمل تعريفي، قم بتخزين الرمز المميز كاعتماد Jenkins أو متغير بيئة عام، ثم استدعِ CLI في مرحلة:

pipeline {
 agent any
 environment {
 APIDOG_ACCESS_TOKEN = credentials('apidog-access-token')
 }
 stages {
 stage('API tests') {
 steps {
 sh 'npm install -g apidog-cli'
 sh 'apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -n 1 -r html,junit --out-dir apidog-reports'
 }
 }
 }
 post {
 always {
 junit 'apidog-reports/*.xml'
 archiveArtifacts artifacts: 'apidog-reports/', allowEmptyArchive: true
 }
 }
}

إذا كان لدى وكلاء البناء لديك CLI مثبتًا ومخزنًا مؤقتًا بالفعل، فاحذف سطر npm install واستدعِ apidog run مباشرة. تقوم خطوة junit في كتلة post بتغذية XML في رسوم بيانية اتجاه الاختبار الخاصة بـ Jenkins؛ ويحتفظ archiveArtifacts بالتقرير HTML مرفقًا بالبناء. إذا كنت تقارن Jenkins ببرامج تشغيل أخرى، فإن المقارنة في إعداد ReadyAPI Jenkins CI، وبديل أبسط تغطي التنازلات.

أنماط ووصفات شائعة

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

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e <prodEnvId> -r cli --on-error end

تراجع كامل ليلي. قم بتشغيل مجلد كامل من السيناريوهات في جدول زمني، مع جمع جميع الإخفاقات في تقرير واحد:

apidog run --access-token $APIDOG_ACCESS_TOKEN -f <folderId> -r html,junit --on-error continue --out-dir ./nightly-reports

تشغيل يعتمد على البيانات. قم بتكرار سيناريو واحد على ملف CSV لحالات الاختبار:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -d ./test-data.csv -r junit

فحص خاص بالفرع. قم بتشغيل السيناريوهات كما هي موجودة في فرع الميزة، وليس main:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 --branch feature-payments -e 1629989 -r cli

تصحيح فشل خاص بـ CI. عندما ينجح سيناريو محليًا ولكنه يفشل في خط الأنابيب، أضف --verbose لرؤية الطلب والاستجابة الدقيقة على مستوى الشبكة التي أنتجها المشغل.

استكشاف الأخطاء وإصلاحها

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

"السيناريو غير موجود." معرف السيناريو، أو معرف المشروع، أو الفرع لا يتطابق. أعد نسخ الأمر من علامة تبويب CI/CD لضمان أن المعرفات حديثة، وتأكد من أن --branch يشير إلى المكان الذي تتوقعه.

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

فشل الشبكة أو TLS ضد المضيفين الداخليين. إذا كانت نقطة النهاية الخاصة بك تستخدم CA داخليًا، فمرر --ssl-extra-ca-certs. استخدم -k فقط كملاذ أخير على المضيفين الداخليين الموثوق بهم حيث تكون الشهادة موقعة ذاتيًا.

يظل البناء أخضر حتى عندما يجب أن يفشل الاختبار. تأكد من أن رمز خروج خطوة apidog run يصل بالفعل إلى CI. إذا قمت بلفه في مسار عمل shell أو ألحقت || true، يتم ابتلاع الخروج غير الصفري وتتوقف البوابة عن العمل. قم بإزالة أي شيء يخفي رمز الخروج.

كيف يتناسب Apidog CLI مع سير العمل الحقيقي

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

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

إذا لم تكن قد أنشأت الاختبارات بعد، فابدأ في التطبيق، واجعل سيناريو واحد ينجح، ثم قم بتوصيل أمر CLI من علامة تبويب CI/CD الخاصة به. قم بتنزيل Apidog لإعداد أول سيناريو مؤتمت لك، وسيكون لديك يراقب مسار عملك في نفس اليوم.

أسئلة مكررة

هل Apidog CLI مجاني؟ CLI نفسه هو حزمة npm مجانية. يمكنك تثبيته باستخدام npm install -g apidog-cli. يُشغّل سيناريوهات الاختبار من مشروع Apidog الخاص بك، لذا فإن ما يمكنك تشغيله يعتمد على خطة Apidog الخاصة بك، لكن مشغل سطر الأوامر ليس منتجًا مدفوعًا منفصلاً.

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

ما الفرق بين Apidog CLI و Newman؟ يقوم Newman بتشغيل مجموعات Postman من سطر الأوامر. يقوم Apidog CLI بتشغيل سيناريوهات اختبار Apidog. الأدوار متوازية، ولكن مشغل Apidog ينفذ السيناريوهات التي قمت بتأليفها في تطبيق Apidog ويتم شحنه كحزمة apidog-cli واحدة. راجع Postman CLI مقابل Newman للجانب المتعلق بـ Postman من تلك المقارنة.

ما تنسيق التقرير الذي يجب استخدامه في CI؟ استخدم junit للحصول على النتيجة القابلة للقراءة آليًا والتي تقوم لوحة معلومات CI الخاصة بك بتحليلها إلى شجرة نجاح/فشل، وأضف html إذا كنت تريد تقريرًا قابلاً للتصفح محفوظًا كجزء بناء. الخيار الشائع هو -r html,junit. احتفظ بـ cli أيضًا إذا كنت تريد إخراجًا قابلاً للقراءة في سجل البناء.

كيف تجعل CLI عملية بناء تفشل؟ من خلال رمز الخروج الخاص بها. عندما يفشل أي تأكيد، يخرج apidog run برمز غير صفري. تقرأ أنظمة CI رمز الخروج هذا، وتضع علامة على الخطوة بأنها فاشلة، وتمنع الدمج أو النشر. لا تحتاج إلى تكوين أي شيء إضافي لكي يعمل هذا.

هل يمكنني تشغيل CLI دون تثبيتها عالميًا؟ نعم. استخدم npx apidog-cli run ... لتنفيذها دون تثبيت عالمي دائم، وهو أمر مريح على مشغلي CI الزائلين.

ما هو إصدار Node.js الذي أحتاجه؟ Node.js v16 أو أحدث. أي صورة CI حديثة تحتوي على Node 16+ تفي بالفعل بالمتطلب.

أين أحصل على رمز الوصول ومعرف السيناريو؟** كلاهما يأتي من علامة تبويب CI/CD الخاصة بسيناريو الاختبار في Apidog. اختر خيار سطر الأوامر، وقم بإنشاء رمز وصول، وانسخ أمر apidog run الكامل الذي يبنيه Apidog لك مع المعرفات المملوءة مسبقًا. ثم انقل الرمز المميز إلى سر CI.