كيفية إضافة أتمتة الاختبار إلى خط أنابيب DevOps الخاص بك

يتم نشر إصدار في الساعة 4 مساءً يوم جمعة. كانت اختبارات الوحدات خضراء، وتم بناء الحاوية، واكتمل الطرح دون أخطاء. ثم تبدأ قائمة الدعم في الامتلاء: صفحة الدفع (checkout) تُرجع أخطاء 500. لم يكن الخطأ أبدًا في الكود الذي تم اختباره. كان في كيفية تحدث خدمتين مع بعضهما البعض، ولم يقم أي اختبار في خط الأنابيب بممارسة هذا الاتصال على الإطلاق.

هذه هي الفجوة التي من المفترض أن تسدها أتمتة الاختبارات في DevOps، والجزء الذي لا تستثمر فيه معظم الفرق بشكل كافٍ هو طبقة واجهة برمجة التطبيقات (API). تثبت اختبارات الوحدات أن الوظيفة تعمل بشكل منعزل. تثبت اختبارات واجهة المستخدم الشاملة (End-to-end UI tests) أن المتصفح يمكنه النقر عبر تدفق، ببطء وبشكل متقطع. يقع العقد بين خدماتك، وهو الشيء الذي يتعطل بالفعل في الإنتاج، في المنتصف وغالبًا ما يمر دون فحص. اختبارات API تعيش هناك بالضبط.

ماذا تعني أتمتة الاختبارات في DevOps فعليًا

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

المبدأ وراء ذلك هو "التحول إلى اليسار" (shift-left): نقل الاختبار مبكرًا، أقرب إلى اللحظة التي يكتب فيها المطور التغيير. يكلف الخطأ الذي يتم اكتشافه في طلب السحب (pull request) دقائق لإصلاحه. نفس الخطأ الذي يتم اكتشافه بعد أسبوع في بيئة التدريج (staging) يكلف مشروع أثري، وقناة حوادث، وتحليل ما بعد الوفاة. الأتمتة هي ما يجعل التحول إلى اليسار ممكنًا، لأن الإنسان لا يستطيع إعادة تشغيل مجموعة اختبارات الانحدار يدويًا في كل commit، ولكن خط الأنابيب يمكنه ذلك.

الخطأ هو التعامل مع "أتمتة الاختبارات" كدلو واحد. يقسم هرم الاختبارات إلى طبقات، وكل طبقة تجيب على سؤال مختلف:

• اختبارات الوحدات (Unit tests) تسأل عما إذا كانت وظيفة واحدة تُرجع القيمة الصحيحة. إنها سريعة وكثيرة العدد.
• اختبارات واجهة برمجة التطبيقات (API) والتكامل (integration tests) تسأل عما إذا كانت خدماتك تنتج استجابات صحيحة وتتحدث مع بعضها البعض بشكل صحيح. هذه الاختبارات أقل عددًا، ولكن كل واحدة تغطي نطاقًا أوسع.
• الاختبارات الشاملة (End-to-end tests) تسأل عما إذا كان النظام بأكمله يعمل من منظور المستخدم. بطيئة، وهشة، ويستحق الإبقاء عليها قليلة.

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

دورة حياة DevOps، مرحلة تلو الأخرى، ومكان ملاءمة اختبارات API

هنا الخريطة العملية. لا يحتاج كل فريق إلى اختبارات API في كل مرحلة، ولكن معرفة الخيارات يتيح لك الاختيار بعناية بدلاً من رمي كل شيء في مهمة واحدة ضخمة قبل النشر.

أثناء التطوير: محليًا وقبل الالتزام (pre-commit)

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

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

على طلبات السحب (pull requests): بوابة الدمج

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

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

بعد البناء، قبل الإصدار: فحوصات التكامل والعقد

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

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

وقت النشر: اختبارات الدخان (smoke tests)

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

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

في الإنتاج: المراقبة المستمرة

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

قاعدة عامة مفيدة عبر المراحل الخمس: كلما اقتربت من الإنتاج، كانت المجموعة أصغر وأسرع. تغطية واسعة على طلبات السحب (PRs) وفي التكامل؛ مجموعة "دخان" (smoke suite) رفيعة وقاسية عند النشر وفي المراقبة.

لماذا تستحق طبقة API مكانها في خط الأنابيب

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

إنها سريعة. يتحدث سيناريو API مباشرة عبر HTTP. لا يوجد متصفح لتشغيله، ولا DOM للانتظار، ولا Chrome بدون واجهة رسومية (headless Chrome) يتقطع بسبب عرض بطيء. سيناريو يقوم بتمرين عشرات نقاط النهاية يكتمل في ثوانٍ، وهذا ما يتيح لك تشغيله في كل commit دون أن يتعلم الناس تجاهل مهمة تستغرق عشر دقائق.

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

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

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

ربط اختبارات API بخط الأنابيب باستخدام Apidog CLI

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

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

قم بتثبيته:

npm install -g apidog-cli

ثم قم بتشغيل سيناريو. تقوم بإنشاء رمز الوصول وتجد معرفات السيناريو والبيئة داخل علامة تبويب CI/CD لسيناريو الاختبار في Apidog، والتي تبني الأمر الكامل لتنسخه:

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

عدة أمور تقوم بعمل حقيقي هنا. تحدد العلامة -t السيناريو بواسطة المعرف؛ استبدلها بـ -f <folderId> لتشغيل مجلد كامل، أو --test-suite <id> لتشغيل مجموعة اختبارات منسقة كمهمة واحدة. تختار العلامة -e البيئة، وهي كيف يقوم نفس السيناريو بحماية طلب سحب مقابل بيئة التدريج واختبار الدخان مقابل الإنتاج بدون تكرار. تختار العلامة -r أدوات الإبلاغ؛ cli تطبع إلى السجل، و junit تُصدر XML يمكن للوحة تحكم CI الخاصة بك عرضها كتقرير اختبار.

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

هنا مرحلة بوابة طلب السحب (PR-gate) المدمجة في GitHub Actions:

name: API Tests
on: [pull_request]

jobs:
  api-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - name: Install Apidog CLI
        run: npm install -g apidog-cli
      - name: Run API scenarios
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
        run: |
          apidog run \
            --access-token "$APIDOG_ACCESS_TOKEN" \
            -t 605067 \
            -e 1629989 \
            -r cli,junit

يعيش الرمز في أسرار المستودع ويصل إلى الخطوة عبر env:، دون ترميز ثابت أبدًا. تسقط نفس الكتلة في GitLab CI أو Jenkins أو CircleCI أو Azure Pipelines مع بناء الجملة الخاص بهذه المنصة حولها، لأن التبعية الحقيقية الوحيدة هي Node. تغطي الإرشادات الخاصة بالمنصة التفاصيل: أتمتة اختبارات API في GitHub Actions و دمج اختبارات Apidog مع Jenkins.

بالنسبة لمرحلة اختبار الدخان (smoke stage) وقت النشر، لا يتغير الأمر كثيرًا. تقوم بتوجيهه إلى معرف بيئة الإنتاج وتبقي السيناريو صغيرًا:

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

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

أخطاء شائعة تُحبط البوابة بصمت

يمكن أن يبدو خط الأنابيب مؤتمتًا بالكامل ومع ذلك لا يكتشف شيئًا. انتبه لهذه الأخطاء.

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

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

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

الاختبار مقابل بيئة قابلة للتغيير ومشتركة. عندما يضرب خطان أنابيب نفس قاعدة البيانات، فإن كتابات تشغيل واحد تسمم قراءات الآخر، وتحصل على أخطاء متقطعة تؤدي إلى تآكل الثقة. استخدم بيئات معزولة، أو استخدم مكوك API (API mocking) لتمثيل التبعيات التي لا تتحكم فيها حتى لا يؤدي تعطل طرف ثالث إلى إحمرار بنائك.

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

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

أين يجب أن تعمل اختبارات API في خط أنابيب DevOps؟

على الأقل، على طلبات السحب (pull requests) كبوابة دمج، حيث أنها تكتشف معظم العيوب بأقل تكلفة. ومن الناحية المثالية أيضًا بعد البناء مقابل بيئة متكاملة لفحوصات العقود، وكـ "مجموعة دخان" (smoke suite) صغيرة مباشرة بعد النشر. يعمل نفس سيناريو Apidog في كل مرحلة؛ أنت تغير فقط علامة البيئة. تتبع الفرق التي تستخدم Apidog بدون Postman نفس مراحل التدريج.

ما الفرق بين أتمتة اختبارات API و CI/CD؟

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

هل أحتاج إلى إعادة كتابة اختبارات API الخاصة بي كرمز لتشغيلها في CI؟

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

كيف تتسبب اختبارات API في فشل بناء؟

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

هل يجب أن تعمل اختبارات الأداء في نفس خط الأنابيب؟

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

أين تضع أول اختبار API لك

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

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