الاختبار في CI واختيار ما لا تختبره

الاختبارات على حاسوبك تحميك أنت. أما الاختبارات في CI (التكامل المستمر) فتحمي الفريق كله، مع كل pull request، سواء تذكّر أحدهم تشغيلها أم لا. يجمع هذا الدرس الأخير القطع معًا: pipeline يشغّل الطبقات التي بنيتها بالترتيب الصحيح، وحسن التقدير في ما يستحق اختبارًا من الأساس.

pipeline من الأسرع إلى الأبطأ

الترتيب مهم بقدر المحتوى. الفحوص الرخيصة التي تفشل كثيرًا تأتي أولًا، فيكلّفك الخطأ المطبعي 30 ثانية من الانتظار بدل 12 دقيقة:

وإليك ذلك على شكل workflow في GitHub Actions:

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

jobs:
  unit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v6
        with:
          node-version: lts/*
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npx tsc --noEmit
      - run: npx vitest run --coverage

  e2e:
    needs: unit
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        shard: [1, 2, 3]
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v6
        with:
          node-version: lts/*
          cache: npm
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test --shard=${{ matrix.shard }}/3
      - uses: actions/upload-artifact@v4
        if: ${{ !cancelled() }}
        with:
          name: playwright-report-${{ matrix.shard }}
          path: playwright-report/
          retention-days: 14

بضعة تفاصيل تؤدّي عملًا حقيقيًا:

• needs: unit يعني أن مهمّة الـ end-to-end لا تبدأ إلا حين تنجح اختبارات الوحدات. لا فائدة من تشغيل المتصفّحات لكود يفشل في tsc.
• --shard=1/3 يقسّم مجموعة Playwright على ثلاثة أجهزة تعمل بالتوازي. (وللحصول على تقرير واحد مدمج، انتقل إلى المُبلّغ blob وشغّل npx playwright merge-reports في مهمّة أخيرة.)
• if: ${{ !cancelled() }} يرفع التقرير حتى حين تفشل الاختبارات، وهذا بالضبط حين تحتاج إلى الـ traces من درس تتبّع الأخطاء.
• CI يُضبط تلقائيًا على خوادم GitHub، فتعمل Vitest مرة واحدة بدل المراقبة، ويفشل أي .only شارد، ويبدأ عمل retries: process.env.CI ? 2 : 0 في إعدادات Playwright.

وأخيرًا، في إعدادات المستودع، اجعل هذه المهامّ فحوص حالة إلزامية (required status checks) على main، كي يمنع الـ pipeline الأحمر الـ merge فعلًا. فالـ pipeline الذي لا يُلزَم أحد بالنجاح فيه مجرّد اقتراح.

اختيار ما لا تختبره

كل اختبار يكلّف وقت كتابة، ودقائق CI، وصيانة. وبعضها يكلّف أكثر مما سيلتقطه في أي وقت:

• الكود التافه: دالة getter تعيد حقلًا، أو ثابت (expect(CURRENCY).toBe('USD') يعيد قول ما في الكود).
• سلوك أطر العمل والمكتبات: أن useState يحدّث الـ state، أو أن Array.prototype.sort يرتّب، أو أن مكتبة التواريخ لديك تنسّق التواريخ. هذا يختبره القائمون على صيانتها.
• التفاصيل الداخلية: أيّ دالة مساعدة خاصة استُدعيت، وكم مرة أُعيد render مكوّن ما، والحالة الداخلية. هذه تفشل مع إعادة الهيكلة وتنجح مع الأخطاء.
• التنسيق: أسماء الأصناف وقيم البكسل في الـ unit tests. وإن كانت الانتكاسات البصرية مهمّة، فاستخدم اختبارات لقطات الشاشة في متصفّح حقيقي لبضع شاشات أساسية.
• الكود المؤقّت: التجارب والنماذج الأولية التي توشك على حذفها.

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

الصورة الكاملة

لديك الآن كل الطبقات: الفحوص الساكنة، والـ unit tests التي تثبّت السلوك والحدود، واختبارات الواجهة التي تتصرّف كالمستخدمين، واختبارات الـ end-to-end التي تنتظر بشكل صحيح وتبقى معزولة، والأدوات للحكم عليها: الـ coverage للفجوات، والـ mutation testing للقوة. والسؤال الذي يقف خلف كل ذلك هو نفسه سؤال الدرس الأول: هل سيفشل هذا الاختبار بسبب خطأ قد يصل فعلًا إلى المستخدمين، بسرعة، وبرسالة تقول ما الذي انكسر؟ احتفظ بالاختبارات التي تجيب بنعم، وأصلح التي يمكن أن تجيب بها، واحذف البقية.

يطلب منك التمرين اتخاذ هذه القرارات على قائمة اختبارات تبدو حقيقية.