كيفية تشغيل اختبارات Apidog CLI API في GitHub Actions (سير عمل كامل)

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

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

زر

باختصار (TL;DR)

إن Apidog CLI هو حزمة npm، apidog-cli. قم بتثبيتها في خطوة سير العمل باستخدام npm install -g apidog-cli، ثم قم بتشغيل السيناريوهات باستخدام apidog run.
يقوم بتنفيذ سيناريوهات الاختبار التي تصممها في تطبيق Apidog بواسطة المعرف (ID). لا تقوم بنقل الاختبارات إلى شيفرة؛ يقوم سطر الأوامر (CLI) بتشغيل نفس السيناريو باستخدام رمز وصول للمصادقة.
تتكون وظيفة GitHub Actions الأساسية من أربع خطوات: سحب المستودع (checkout)، إعداد Node، تثبيت سطر الأوامر (CLI)، تشغيل apidog run --access-token "$APIDOG_ACCESS_TOKEN" -t <scenarioId> -e <environmentId> -r junit,cli.
يخرج سطر الأوامر (CLI) برمز غير صفري عندما يفشل أي تأكيد. يقرأ GitHub رمز الخروج هذا، ويفشل التحقق، ويحظر الدمج. هذه هي بوابة الجودة بأكملها؛ لا تقوم بتكوين أي شيء إضافي.
قم بتخزين رمز الوصول كسر في GitHub Actions وقم بتمريره عبر env:. لا تقم أبدًا بإيداعه في المستودع.
استخدم -r junit لتغذية النتائج في لوحة التحكم، و -r html لمادة عرض قابلة للتصفح (artifact)، و if: always() في خطوة الرفع لكي تحصل على التقرير حتى عندما تفشل الاختبارات.

لماذا تشغيل اختبارات الـ API في CI على الإطلاق؟

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

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

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

ما يفعله Apidog CLI بالفعل

هذا هو الجزء الذي يوفر عليك معظم الوقت: أنت لا تكتب شيفرة اختبار لـ CLI.

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

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

البرنامج التنفيذي هو apidog، ويتم توزيعه كحزمة npm باسم apidog-cli. تبدأ كل الأوامر بـ apidog run. إذا كنت ترغب في رؤية المشغل منسوجًا في سير عمل أتمتة أكثر اكتمالًا، فإن الشرح التفصيلي حول دمج Apidog CLI مع Claude Skills لأتمتة اختبار API يغطي تلك الزاوية؛ بينما تركز هذه المقالة على العلامات التي تحتاجها لمسار عمل GitHub Actions.

قبل أن تبدأ: ثلاثة أشياء تحتاجها

تحتاج إلى ثلاث معلومات قبل أن يبدأ سير العمل. اثنتان هما معرفات (IDs) من مشروع Apidog الخاص بك؛ وواحدة هي رمز.

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

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

قاعدة واحدة تستحق الذكر مقدمًا: تعامل مع رمز الوصول ككلمة مرور. لا تلصقه في ملف سير عمل ملتزم به (committed workflow file). قم بتخزينه كسر في GitHub Actions وقم بالإشارة إليه كمتغير بيئة. يستخدم كل مثال أدناه $APIDOG_ACCESS_TOKEN لهذا السبب تحديدًا.

الخطوة 1: تخزين رمز الوصول كسر في GitHub

افتح مستودعك على GitHub. اذهب إلى الإعدادات (Settings)، ثم الأسرار والمتغيرات (Secrets and variables)، ثم الإجراءات (Actions)، وانقر على سر مستودع جديد (New repository secret).

الاسم: APIDOG_ACCESS_TOKEN
السر: الصق الرمز الذي أنشأه Apidog لك

احفظه. أصبح الرمز الآن مشفرًا في حالة السكون ومكشوفًا فقط لعمليات تشغيل سير العمل، ولا تتم طباعته أبدًا في السجلات. في سير العمل، ستقوم بالإشارة إليه كـ ${{ secrets.APIDOG_ACCESS_TOKEN }} وتمريره إلى CLI عبر كتلة env:. معرف السيناريو ومعرف البيئة ليسا سريين؛ إنهما معرفات غير ضارة، لذا يمكنك كتابتها مباشرة في ملف سير العمل. الرمز فقط هو الذي يحتاج إلى حماية.

إذا كان فريقك يعمل عبر عدة مستودعات تستخدم نفس مشروع Apidog، فقم بتعريف السر مرة واحدة على مستوى المؤسسة بدلاً من ذلك وامنح المستودعات ذات الصلة حق الوصول. نفس الاسم، ومكان واحد لتدويره.

الخطوة 2: سير العمل الأدنى

قم بإنشاء .github/workflows/api-tests.yml في مستودعك. هذا هو أصغر سير عمل يقوم بشيء مفيد: يقوم بتشغيل السيناريو الخاص بك على كل طلب سحب يستهدف الفرع main.

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 \
            -r cli
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

استبدل 605067 بمعرف السيناريو الخاص بك و 1629989 بمعرف البيئة الخاص بك. قم بإيداع هذا الملف، وافتح طلب سحب، وراقب علامة تبويب التحققات (Checks). تقوم الوظيفة بتشغيل مشغل Ubuntu، وتثبيت Node 20، وتثبيت سطر الأوامر (CLI)، وتشغيل السيناريو الخاص بك. إذا نجحت جميع التأكيدات، يصبح التحقق أخضر. إذا فشل أحدها، يخرج apidog run برمز غير صفري، ويفشل GitHub التحقق، ويظهر طلب السحب علامة X حمراء.

هذه العلامة X الحمراء هي بيت القصيد. لا يحتاج أحد لقراءة سجل لمعرفة أن شيئًا ما قد تعطل؛ التحقق الفاشل موجود مباشرة على طلب السحب.

ملاحظة حول خطوة التثبيت: الأمر العام npm install -g apidog-cli بسيط ويعمل. إذا كنت تفضل عدم تعديل الحزم العامة للمشغل، يمكنك تخطي خطوة التثبيت واستدعاء CLI عبر npx بدلاً من ذلك:

      - name: Run API test scenario
        run: npx apidog-cli run --access-token "$APIDOG_ACCESS_TOKEN" -t 605067 -e 1629989 -r cli
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

كلا الطريقتين تشغلان السيناريو المتطابق. npx أكثر تنظيمًا على المشغلات المؤقتة؛ التثبيت العام أسرع قليلاً عندما تقوم بتخزين node_modules مؤقتًا بين عمليات التشغيل. اختر ما يناسب أسلوبك.

الخطوة 3: نشر تقرير يمكنك قراءته بالفعل

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

تتحكم العلامة -r (أو --reporters) في تنسيقات التقارير. وهي تقبل cli، html، json، و junit، مفصولة بفاصلة. بالنسبة للتكامل المستمر (CI)، هناك تنسيقان يستحقان مكانهما:

يقوم junit بإصدار XML بتنسيق JUnit القياسي. تعرف جميع لوحات تحكم CI وأدوات الإبلاغ عن الاختبارات تقريبًا كيفية تحليله إلى شجرة نجاح/فشل.
ينتج html تقريرًا قائمًا بذاته يمكنك حفظه كمادة عرض (artifact) للبناء وفتحه في المتصفح، مع الطلب والاستجابة الكاملين لكل خطوة.

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

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

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

تفصيلان يجعلان هذا يعمل بالطريقة التي تريدها. تخبر العلامة --out-dir سطر الأوامر (CLI) بمكان كتابة التقارير؛ هنا هو ./apidog-reports، والذي تقوم خطوة التحميل بجلبه لاحقًا. و if: always() في خطوة التحميل هو الأمر المهم: افتراضيًا، يتخطى GitHub الخطوات اللاحقة بمجرد فشل خطوة ما، لكنك تريد التقرير أكثر عندما تفشل الاختبارات. يجبر if: always() عملية التحميل على العمل بغض النظر عن نتيجة الاختبار. بعد انتهاء الوظيفة، يظهر التقرير تحت Artifacts في صفحة ملخص التشغيل، جاهزًا للتنزيل.

تحدد العلامة -n 1 عدد التكرارات لعملية تشغيل واحدة؛ قم بزيادتها إذا كنت تريد تنفيذ السيناريو عدة مرات متتالية.

إذا كنت تريد أن يعرض GitHub نتائج JUnit مضمنة كتحقق مشروح بدلاً من ملف قابل للتنزيل، فأضف إجراء published-test-results بعد خطوة التشغيل ووجهه إلى ./apidog-reports/*.xml. يحول ذلك ملف XML إلى ملخص نجاح/فشل مرفق بالتشغيل، وهو مفيد للمجموعات الأكبر حيث لا يكون التمرير في السجل عمليًا.

الخطوة 4: اختبار البيئة الصحيحة في الوقت المناسب

يجب أن يقوم طلب السحب بالاختبار مقابل بيئة الاختبار (staging). يجب التحقق من النشر إلى بيئة الإنتاج (production) مقابل بيئة الإنتاج. يمكن لنفس السيناريو أن يفعل الأمرين؛ ما عليك سوى تغيير معرف البيئة باستخدام -e.

يستخدم إعداد شائع ودائم محفزين في ملف سير عمل واحد. تشغل طلبات السحب السيناريو مقابل بيئة الاختبار (staging) الخاصة بك كبوابة دمج. وتشغل عمليات الدفع إلى main (وهو ما ينتجه الدمج) نفس السيناريو مقابل الإنتاج كاختبار سريع بعد النشر.

name: API tests

on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  pr-check:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install -g apidog-cli
      - name: Test staging
        run: |
          apidog run \
            --access-token "$APIDOG_ACCESS_TOKEN" \
            -t 605067 \
            -e 1629989 \
            -r junit,cli \
            --out-dir ./apidog-reports
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: staging-report
          path: ./apidog-reports

  prod-smoke:
    if: github.event_name == 'push'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install -g apidog-cli
      - name: Smoke test production
        run: |
          apidog run \
            --access-token "$APIDOG_ACCESS_TOKEN" \
            -t 605067 \
            -e 1730055 \
            -r cli \
            --on-error end
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

معرفي البيئة (1629989 لبيئة الاختبار، 1730055 لبيئة الإنتاج) هما الفرق الوحيد ذو المعنى. تقوم وظيفة طلب السحب ببناء وأرشفة تقرير JUnit حتى يتمكن المراجعون من فحص الإخفاقات؛ بينما يعمل اختبار الدخان للإنتاج (production smoke test) بشكل فعال ويفشل بسرعة مع --on-error end، والذي يتوقف عند أول تأكيد معطل لتكتشف بسرعة أن النشر قد حدث بشكل خاطئ.

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

متابعة: تشغيل المصفوفات، المجلدات، والاختبارات المعتمدة على البيانات

بمجرد تثبيت البوابة الأساسية، تقوم بعض العلامات بتوسيعها دون الحاجة إلى الكثير من YAML الإضافي.

قم بتشغيل منطقة ميزة كاملة، وليس سيناريو واحدًا. استبدل -t <scenarioId> بـ -f <folderId> لتشغيل كل سيناريو داخل مجلد، أو --test-suite <testSuiteId> لتشغيل مجموعة منسقة. المجموعات هي الأداة المناسبة عندما تريد تشغيل مجموعة محددة ومرتبة من السيناريوهات معًا كوظيفة منطقية واحدة؛ يغطي الدليل حول توسيع نطاق اختبار API التلقائي باستخدام مجموعات الاختبار متى يجب اللجوء إليها.

اختبار عدة بيئات بالتوازي. تقوم المصفوفة بتشغيل نفس الوظيفة عبر عدة معرفات بيئة في وقت واحد:

jobs:
  api-tests:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        env-id: [1629989, 1730055]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install -g apidog-cli
      - name: Run scenario against ${{ matrix.env-id }}
        run: |
          apidog run \
            --access-token "$APIDOG_ACCESS_TOKEN" \
            -t 605067 \
            -e ${{ matrix.env-id }} \
            -r cli
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

يقوم GitHub بتشغيل مشغل واحد لكل قيمة مصفوفة، بحيث يتم اختبار بيئة الاختبار والإنتاج بشكل متزامن وكل منهما يبلغ عن حالته نجاح/فشل.

قم بتشغيل التكرارات من ملف بيانات. تقوم العلامة -d بتشغيل سيناريو واحد عبر صفوف ملف CSV أو JSON، مع معاملة كل صف كمرور منفصل: apidog run --access-token "$APIDOG_ACCESS_TOKEN" -t 605067 -d ./test-data.csv -r junit. هذه هي الطريقة التي تتحقق بها من نفس نقطة النهاية مقابل خمسين مدخلًا دون بناء خمسين سيناريو.

التشغيل مقابل فرع. إذا كان فريقك يستخدم ميزة الفروع في Apidog، فإن --branch <branchName> يوجه التشغيل إلى فرع معين بدلاً من main، مما يسمح لطلب السحب لفرع الميزة بالاختبار مقابل تعريفات السيناريو الخاصة بذلك الفرع.

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

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

فشل المصادقة. السبب الأكثر شيوعًا هو عدم تطابق اسم السر. يجب أن يستخدم مفتاح env:، والإشارة إلى القيمة ${{ secrets.APIDOG_ACCESS_TOKEN }}، والسر الذي أنشأته في الإعدادات، نفس الاسم. تأكد أيضًا من أن الرمز لم يتم إعادة إنشائه في Apidog منذ أن قمت بحفظه؛ إعادة الإنشاء تبطل الرمز القديم.

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

التقارير لا تظهر كمواد عرض (artifacts). تأكد من أن --out-dir في خطوة التشغيل و path: في خطوة التحميل يشيران إلى نفس الدليل، وأن خطوة التحميل تحتوي على if: always(). بدون if: always()، يتخطى الاختبار الفاشل عملية التحميل وتفقد التقرير بالضبط عندما تكون في أمس الحاجة إليه.

لا يمكن للمشغل الوصول إلى API الخاص بك. إذا كانت بيئة الاختبار (staging) أو الإنتاج (production) الخاصة بك تقع خلف جدار حماية (firewall) أو شبكة افتراضية خاصة (VPN)، فلا يمكن للمشغل المستضاف على GitHub الوصول إليها. ستحتاج إلى مشغل مستضاف ذاتيًا داخل شبكتك، أو إدخال في قائمة السماح لنطاقات IP الخاصة بـ GitHub.

كيف يقارن هذا بالبدائل

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

يمكنك أيضًا كتابة نصوص لأوامر curl الخام في خطوة سير عمل. هذا جيد لتحقق واحد من الصحة، ولكنه مؤلم بعد ذلك، لأنك تقوم بتنفيذ التأكيدات يدويًا، وتبديل البيئات، وإعداد التقارير التي يوفرها لك CLI مجانًا.

GitHub Actions ليس المنزل الوحيد لذلك أيضًا. يمكن استخدام نفس أمر apidog run بالضبط في GitLab CI، Jenkins، CircleCI، أو أي مشغل يمكنه تنفيذ أمر shell وقراءة رمز الخروج. إذا لم تكن GitHub Actions هي منصتك، فإن الأنماط هنا تنتقل مباشرة؛ راجع دليل أتمتة اختبارات الـ API في CI/CD للحصول على نظرة شاملة للمنصات، أو الشرح التفصيلي حول دمج اختبارات Apidog المؤتمتة مع Jenkins إذا كنت تستخدم Jenkins.

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

خاتمة

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

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

زر