الاختبارات على حاسوبك تحميك أنت. أما الاختبارات في CI (التكامل المستمر) فتحمي الفريق كله، مع كل pull request، سواء تذكّر أحدهم تشغيلها أم لا. يجمع هذا الدرس الأخير القطع معًا: pipeline يشغّل الطبقات التي بنيتها بالترتيب الصحيح، وحسن التقدير في ما يستحق اختبارًا من الأساس.
\nالترتيب مهم بقدر المحتوى. الفحوص الرخيصة التي تفشل كثيرًا تأتي أولًا، فيكلّفك الخطأ المطبعي 30 ثانية من الانتظار بدل 12 دقيقة:
\nوإليك ذلك على شكل workflow في GitHub Actions:
\nname: Test\non:\n pull_request:\n push:\n branches: [main]\n\njobs:\n unit:\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v6\n - uses: actions/setup-node@v6\n with:\n node-version: lts/*\n cache: npm\n - run: npm ci\n - run: npm run lint\n - run: npx tsc --noEmit\n - run: npx vitest run --coverage\n\n e2e:\n needs: unit\n runs-on: ubuntu-latest\n strategy:\n fail-fast: false\n matrix:\n shard: [1, 2, 3]\n steps:\n - uses: actions/checkout@v6\n - uses: actions/setup-node@v6\n with:\n node-version: lts/*\n cache: npm\n - run: npm ci\n - run: npx playwright install --with-deps\n - run: npx playwright test --shard=${{ matrix.shard }}/3\n - uses: actions/upload-artifact@v4\n if: ${{ !cancelled() }}\n with:\n name: playwright-report-${{ matrix.shard }}\n path: playwright-report/\n retention-days: 14بضعة تفاصيل تؤدّي عملًا حقيقيًا:
\nneeds: 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، وصيانة. وبعضها يكلّف أكثر مما سيلتقطه في أي وقت:
\nexpect(CURRENCY).toBe('USD') يعيد قول ما في الكود).useState يحدّث الـ state، أو أن Array.prototype.sort يرتّب، أو أن مكتبة التواريخ لديك تنسّق التواريخ. هذا يختبره القائمون على صيانتها.وكن مستعدًا للحذف. الاختبار الذي لم يفشل قط لسبب حقيقي خلال عامين، أو الذي ينكسر مع كل إعادة هيكلة، أو المتخطّى بشكل دائم، عبء. وحذفه مساهمة.
\n\nلديك الآن كل الطبقات: الفحوص الساكنة، والـ unit tests التي تثبّت السلوك والحدود، واختبارات الواجهة التي تتصرّف كالمستخدمين، واختبارات الـ end-to-end التي تنتظر بشكل صحيح وتبقى معزولة، والأدوات للحكم عليها: الـ coverage للفجوات، والـ mutation testing للقوة. والسؤال الذي يقف خلف كل ذلك هو نفسه سؤال الدرس الأول: هل سيفشل هذا الاختبار بسبب خطأ قد يصل فعلًا إلى المستخدمين، بسرعة، وبرسالة تقول ما الذي انكسر؟ احتفظ بالاختبارات التي تجيب بنعم، وأصلح التي يمكن أن تجيب بها، واحذف البقية.
\nيطلب منك التمرين اتخاذ هذه القرارات على قائمة اختبارات تبدو حقيقية.
\n","toc":[{"id":"sec-1","text":"pipeline من الأسرع إلى الأبطأ","level":2},{"id":"sec-2","text":"اختيار ما لا تختبره","level":2},{"id":"sec-3","text":"الصورة الكاملة","level":2}],"takeaways":["رتّب CI من الأسرع إلى الأبطأ (الـ lint والأنواع، ثم اختبارات unit وintegration، ثم end-to-end) كي توقف حالات الفشل الرخيصة التشغيل مبكرًا.","اجعل مهامّ الاختبار فحوصًا إلزامية (required checks) على الفرع الرئيسي، وارفع تقارير Playwright كـ artifacts، ووزّع مجموعات الـ end-to-end البطيئة على عدة أجهزة بالـ sharding.","أبقِ الـ pipeline كله سريعًا بما يكفي كي ينتظره الناس؛ فالـ pipeline الذي يستغرق 40 دقيقة يُتجاوَز.","لا تختبر الكود التافه، ولا سلوك أطر العمل أو المكتبات، ولا التنسيق، ولا التفاصيل الداخلية؛ واحذف الاختبارات التي لا تفشل أبدًا لسبب حقيقي.","يستحق الاختبار مكانه حين يفشل بسبب خطأ قد يصل فعلًا إلى المستخدمين، بسرعة، وبرسالة واضحة."],"further":[{"title":"Playwright — Continuous Integration","url":"https://playwright.dev/docs/ci-intro"},{"title":"Playwright — Sharding","url":"https://playwright.dev/docs/test-sharding"},{"title":"GitHub Docs — About protected branches","url":"https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches"},{"title":"Vitest — Reporters","url":"https://vitest.dev/guide/reporters"}],"quiz":[{"q":"يشغّل الـ pipeline لديك Playwright أولًا (12 دقيقة)، ثم الـ lint (20 ثانية). خطأ مطبعي في import يُفشل الـ lint في معظم الـ pull requests المعطوبة. ما الترتيب الأفضل؟
","options":[{"text":"أبقِ الترتيب؛ اختبارات الـ end-to-end هي الأهم، فيجب أن تعمل أولًا.","why":"الأهمية ليست المقصود؛ تشغيل أبطأ مهمّة أولًا يعني أن المطوّرين ينتظرون 12 دقيقة ليعرفوا بمشكلة تستغرق 20 ثانية."},{"text":"الـ lint وفحص الأنواع أولًا، ثم اختبارات unit وintegration، ثم end-to-end فقط إن نجح ما قبلها.","why":"صحيح. الفحوص السريعة الرخيصة تفشل مبكرًا وتوفّر دقائق التشغيل؛ والمرحلة البطيئة لا تعمل إلا على كود معقول أصلًا."},{"text":"شغّل الـ lint على الفرع الرئيسي فقط بعد الـ merge.","why":"عندها يصل الكود المعطوب إلى main قبل أن يلاحظه أحد، وهذا بالضبط ما وُجد CI على الـ pull requests لمنعه."}],"answer":1},{"q":"أيّ من هذه الاختبارات هو أفضل مرشّح للحذف؟
","options":[{"text":"اختبار انتكاس لخطأ مبلَّغ عنه كانت فيه'12.5' تُحلَّل على أنها 1205 سنتًا.","why":"اختبارات الانتكاس للأخطاء الحقيقية من أثمن الاختبارات التي تملكها؛ ذلك الخطأ حدث مرة ويمكن أن يحدث مجددًا."},{"text":"اختبار يعرض مكوّنًا ويتحقّق من أن دالة الضبط في useState الخاص بـ React تحدّث الـ state.","why":"صحيح. إنه يختبر React، لا كودك. مجموعة اختبارات React نفسها تغطّي ذلك، ولا يمكن أن يفشل الاختبار إلا إن كانت React نفسها معطّلة."},{"text":"اختبار end-to-end يضيف مصروفًا ويتحقّق من أن الأرصدة تتحدّث.","why":"هذا مسار حرج يكون فيه الاتصال بين الواجهة والـ API والمنطق هو الخطر، وهو بالضبط ما وُجدت اختبارات الـ end-to-end من أجله."}],"answer":1},{"q":"كبرت مجموعة الـ end-to-end حتى صارت تستغرق 30 دقيقة على جهاز واحد. ما الخطوة الأولى الأكثر فاعلية؟
","options":[{"text":"وزّعها على عدة أجهزة بـ--shard، وتحقّق إن كانت بعض اختبارات الـ end-to-end تكرّر اختبارات في مستويات أدنى.","why":"صحيح. الـ sharding يقلّص الوقت الفعلي فورًا؛ ونقل الفحوص المكرّرة إلى أسفل الكأس يقلّص العمل الكلي."},{"text":"شغّل مجموعة الـ end-to-end مرة واحدة في الأسبوع فقط.","why":"عندها تتراكم تغييرات أسبوع كامل قبل أن يعرف أحد أن مسارًا حرجًا انكسر، ويصبح إيجاد المتسبّب أصعب بكثير."},{"text":"زِد مهلة كل اختبار كي يفشل عدد أقل منها.","why":"المهل ليست المشكلة هنا، والمهل الأطول تجعل المجموعة البطيئة أبطأ حين يسوء شيء ما فعلًا."}],"answer":0}],"exercise":{"kind":"choice","multiple":true,"options":["page-snapshot","negative-format","usestate","settle-e2e","constant","private-spy","regression","network-404"],"correct":["page-snapshot","usestate","constant","private-spy"],"title":"تحتفظ به أم تحذفه؟","prompt":"ورثت مجموعة اختبارات Splitwise-lite. يستغرق CI خمسًا وعشرين دقيقة، والفريق يريده أسرع دون أن يفقد الثقة. اختر كل اختبار ستحذفه (أو لن تكتبه من الأساس). واترك دون اختيار الاختبارات التي تستحق مكانها.
\n","hints":["لكل اختبار، اسأل: أيّ خطأ معقول سيجعله يفشل؟ إن كانت الإجابة “إعادة هيكلة فقط” أو “خطأ في React فقط”، فهو مرشّح للحذف.","اختبارات الانتكاس للأخطاء الحقيقية واختبارات الحالات الحدّية في المال نادرًا ما تكون هي التي تُحذف."],"explanation":"احذف أربعة. الـ snapshot للصفحة كلها يفشل مع كل تعديل في البنية ويعلّم الناس الضغط على “update” دون قراءة. واختبار useState يفحص React، لا Splitwise-lite. واختبار الثابت يعيد قول سطر من الكود، ولا يمكن أن يفشل إلا حين يغيّر أحدهم القيمة عن قصد. والـ spy على دالة مساعدة خاصة يفشل مع إعادة الهيكلة وينجح مع الأخطاء الحقيقية. واحتفظ بالأربعة الأخرى: تنسيق المبلغ السالب حالة حدّية في المال؛ واختبار الـ end-to-end للتسوية يغطّي المسار الذي تلتقي فيه الواجهة والـ API والمنطق؛ واختبار الانتكاس يوثّق خطأً وصل فعلًا إلى المستخدمين؛ واختبار 404 يغطّي معالجة أخطاء يصادفها المستخدمون مع الروابط المعطوبة. ولتسريع CI، اجمع بين هذا الحذف والـ sharding ونقل فحوص الـ end-to-end المكرّرة إلى اختبارات المكوّنات.
expect(container).toMatchSnapshot() على صفحة المجموعة المعروضة كاملة (snapshot من 400 سطر).","why":"احذفه. يفشل مع كل تغيير غير ضارّ في البنية ولا يقول شيئًا عن السلوك المهم، فيوافق المراجعون على التحديثات دون تمحيص."},"negative-format":{"text":"expect(formatMoney(-505)).toBe('-$5.05')","why":"احتفظ به. المبالغ السالبة وإكمال الصفر هي بالضبط مواضع انكسار تنسيق المال، والاختبار يعمل في جزء من الثانية."},"usestate":{"text":"اختبار يعرض مكوّنًا، ويستدعي دالة الضبط في useState عبر hook اختبار، ويتحقّق من أن الـ state تغيّر.","why":"احذفه. يختبر سلوك React نفسها، الذي تغطّيه مجموعة اختبارات React أصلًا؛ ولا يمكن أن يفشل بسبب كودك."},"settle-e2e":{"text":"اختبار Playwright: أضف مصروفًا، وانقر Settle up، وتوقّع “Everyone is settled up”.","why":"احتفظ به. إنه المسار الأساسي، ولا يتحقّق من أن الواجهة والـ API ومنطق التسوية تعمل معًا إلا اختبار end-to-end."},"constant":{"text":"expect(DEFAULT_CURRENCY).toBe('USD')","why":"احذفه. يعيد قول الكود المصدري. لا يفشل إلا حين يغيّر أحدهم الثابت عمدًا، وعندها يحتاج هو أيضًا إلى تحديث فحسب."},"private-spy":{"text":"اختبار يتجسّس على الدالة المساعدة الداخلية _sortDebtors ويؤكّد أن settleUp استدعتها مرة واحدة بالضبط.","why":"احذفه. يجمّد تفصيلًا داخليًا: دمج الدالة المساعدة أو إعادة تسميتها يكسره، بينما تنجح معه تسوية خاطئة."},"regression":{"text":"اختبار انتكاس من تقرير خطأ الربيع الماضي: expect(parseAmount('12.5')).toBe(1250).","why":"احتفظ به. هذا الخطأ وصل فعلًا إلى المستخدمين مرة؛ والاختبار يضمن ألا يعود بصمت أبدًا."},"network-404":{"text":"اختبار يتحقّق من أن loadGroup تُرفض بالرسالة “HTTP 404” حين يجيب الـ API بـ 404.","why":"احتفظ به. معالجة الأخطاء هي حيث تختبئ الأخطاء، والروابط المعطوبة أو القديمة تجعل 404 مسارًا حقيقيًا للمستخدم."}}},"words":572,"readMinutes":3}