في الربيع الماضي غيّر زميل لي سطرًا واحدًا في دالة مساعدة لتقسيم الفواتير: صار Math.round هو Math.floor، كي “يصلح” حصّة بدت أعلى بسنت واحد. ظلّت كل الشاشات تعمل. وبعد ثلاثة أسابيع لاحظ مستخدم أن أرصدة مجموعته لم يعد مجموعها صفرًا، ولم يستطع أحد أن يحدّد أيّ واحد من 200 commit كان السبب. اختبار واحد من ثلاثة أسطر كان سيفشل خلال ثانية من ذلك التغيير.
هذا بالضبط ما تمنحك إياه الاختبارات: الثقة لتغيير الكود بسرعة. بدونها تصبح كل إعادة هيكلة (refactoring) مقامرة، ويحتاج كل إصدار إلى شخص يتنقّل في التطبيق نقرةً نقرة. ومع اختبارات جيدة، تغيّر الكود، وتشغّل مجموعة الاختبارات (suite)، فتعرف النتيجة.
\nانزع عنه كل أطر العمل، وسيبقى الاختبار كودًا يشغّل كودك ويرمي خطأً حين تكون النتيجة خاطئة:
\nfunction splitEvenly(totalCents, people) {\n const base = Math.floor(totalCents / people);\n const remainder = totalCents % people;\n return Array.from({ length: people }, (_, i) => (i < remainder ? base + 1 : base));\n}\n\nconst shares = splitEvenly(1000, 3);\nconst sum = shares.reduce((a, b) => a + b, 0);\nif (sum !== 1000) throw new Error(`Expected shares to add up to 1000, got ${sum}`);\nconsole.log('PASS shares add up to the total', shares);تضيف Vitest وJest وPlaywright الكثير فوق ذلك: رسائل فشل واضحة، ووضع المراقبة (watch mode)، والتشغيل المتوازي، والمتصفّحات. لكن في العمق، expect(sum).toBe(1000) ليست سوى if ترمي خطأً.
كل اختبار كود عليك صيانته. يأخذ وقتًا لكتابته، ودقائق من CI لتشغيله، وانتباهًا حين يفشل. والاختبار الذي يفشل دون أن يكون شيء معطّلًا (الـ flaky test أو الاختبار المتقلّب، أو الاختبار الهشّ) أسوأ من غيابه: فالناس يتعلّمون تجاهل البناء الأحمر. لذا فالسؤال ليس أبدًا “كم اختبارًا؟” بل كم من الثقة يشتري كل اختبار مقابل كل دقيقة من CI.
\nكأس الاختبارات (testing trophy) طريقة شائعة لتصوّر الطبقات ومقدار ما تكتبه من كل منها:
\nالقاعدة التي أستعملها كل يوم: اختر أرخص اختبار يمكن أن يفشل لو انكسر الشيء الذي يقلقك.
\nالمشروع الذي يرافقك طوال الدورة هو Splitwise-lite، وحدة برمجية لتقسيم الفواتير في رحلة جماعية: تحليل المبالغ، وتقسيم الفواتير، وإضافة البقشيش، وحساب من يدين لمن، وتسوية الحسابات، إضافة إلى واجهة صغيرة وطبقة شبكة. في ساحة التجربة تحصل على كود يعمل وتكتب اختبارات له. ثم يشغّل المدقّق اختباراتك على نسخ معطوبة عمدًا (تقريب خاطئ، أو خطأ بفارق واحد، أو معاملات متبادلة الموقع)، وعلى اختباراتك أن تلتقط كل واحدة منها. النجاح على الكود السليم نصف المهمة؛ والفشل على الكود المعطوب هو النصف الآخر.
\nقبل أن تثبّت أي شيء، ابنِ الفكرة الأساسية بنفسك في التمرين التالي: assertion (تأكيد) يرمي خطأً، ومشغّل اختبارات (test runner) يلتقطه.
\n","toc":[{"id":"sec-1","text":"ما هو الاختبار","level":2},{"id":"sec-2","text":"للاختبارات تكلفة أيضًا","level":2},{"id":"sec-3","text":"كأس الاختبارات","level":2},{"id":"sec-4","text":"ما الذي ستبنيه في هذه الدورة","level":2}],"takeaways":["الاختبار كود يشغّل كودك ويرمي خطأً حين تكون النتيجة خاطئة؛ وكل إطار عمل للاختبار مجرّد غلاف أجمل حول هذه الفكرة.","تمنحك الاختبارات الثقة لتغيير الكود بسرعة؛ أما الاختبار الذي لا يلتقط خطأً أبدًا ولا يوثّق شيئًا فتكلفته أكبر من فائدته.","لكأس الاختبارات (testing trophy) أربع طبقات (التحليل الساكن، والـ unit، والـ integration، والـ end-to-end)، وعادةً ما تمنحك الـ integration tests أكبر قدر من الثقة مقابل كل دقيقة من وقت CI.","اختر أرخص اختبار يمكن أن يفشل لو انكسر الشيء الذي يقلقك."],"further":[{"title":"Vitest — Why Vitest","url":"https://vitest.dev/guide/why"},{"title":"Playwright — Getting started","url":"https://playwright.dev/docs/intro"},{"title":"Testing Library — Guiding principles","url":"https://testing-library.com/docs/guiding-principles"}],"quiz":[{"q":"يقرّب Splitwise-lite حصّة كل شخص إلى أقرب سنت كامل. أيّ اختبار يعطيك أسرع إشارة وأدقّها على أن التقريب صحيح؟
","options":[{"text":"اختبار end-to-end يضيف مصروفًا في المتصفّح ثم يقرأ الرصيد.","why":"سيلتقط الخطأ، لكنه بطيء، ويحتاج إلى تطبيق يعمل، وحين يفشل يشير إلى النظام كله لا إلى دالة التقريب."},{"text":"unit test يستدعي دالة التقسيم بـ 1000 سنت و3 أشخاص.","why":"صحيح. التقريب منطق صافٍ له حالات حدّية كثيرة، لذا فإن unit test يستغرق جزءًا من الثانية هو أرخص اختبار يفشل تمامًا حين ينكسر التقريب."},{"text":"فحص أنواع TypeScript على توقيع الدالة.","why":"تؤكّد الأنواع أن الدالة تستقبل أرقامًا وتعيد أرقامًا، لكنها لا تميّز 334 من 333؛ التقريب مسألة قيم لا مسألة أنواع."}],"answer":1},{"q":"ماذا يفعل إطار الاختبار في جوهره حين يفشل assertion؟
","options":[{"text":"يعدّل الكود المصدري كي ينجح الـ assertion في المرة القادمة.","why":"لا يوجد إطار يغيّر كودك؛ الاختبار الفاشل معلومة لك أنت كي تتصرّف بناءً عليها."},{"text":"يسجّل تحذيرًا ويُبقي الاختبار أخضر.","why":"الاختبار الذي يبقى أخضر رغم فشل الـ assertion لا فائدة منه؛ الأطر تعلّم الاختبار بأنه فاشل."},{"text":"يرمي الـ assertion خطأً، فيلتقطه مشغّل الاختبارات، ويعلّم ذلك الاختبار بأنه فاشل، ثم ينتقل إلى التالي.","why":"صحيح.expect(...).toBe(...) ترمي خطأً عند عدم التطابق؛ والمشغّل يلفّ كل اختبار بـ try/catch ويبلّغ عن النتيجة."}],"answer":2},{"q":"تستغرق مجموعة اختبارات الـ end-to-end في فريقك 40 دقيقة، وتفشل عشوائيًا مرة في اليوم تقريبًا. أيّ تغيير يرفع الثقة مقابل كل دقيقة من CI أكثر من غيره؟
","options":[{"text":"انقل معظم فحوص المنطق إلى اختبارات integration وunit، واحتفظ ببضعة اختبارات end-to-end للمسارات الحرجة.","why":"صحيح. الطبقات الأدنى تفحص المنطق نفسه في أجزاء من الثانية دون تقلّب المتصفّح؛ وبضعة اختبارات end-to-end تبقى كافية لإثبات أن القطع متّصلة ببعضها."},{"text":"أضف إعادة محاولة تلقائية حتى ينجح كل اختبار.","why":"إعادة المحاولة تُخفي التقلّب بدل أن تصلحه، وتجعل المجموعة أبطأ؛ والأخطاء الحقيقية التي تفشل بشكل متقطّع تضيع هي الأخرى بين المحاولات."},{"text":"احذف مجموعة الـ end-to-end واعتمد على الـ unit tests وحدها.","why":"قد تنجح كل الـ unit tests والتطبيق معطّل، كأن لا يستدعي النموذج الدالة التي تختبرها أصلًا. ما زلت تحتاج إلى بضعة اختبارات end-to-end."}],"answer":0}],"exercise":{"kind":"web","mode":"js","starter":{"js":"// An assertion: throw an Error when actual !== expected.\nfunction expectEqual(actual, expected) {\n // your code\n}\n\n// A runner: run fn, log PASS or FAIL, never let one failure stop the others.\nfunction test(name, fn) {\n // your code\n}\n\ntest(\"two plus two\", () => expectEqual(2 + 2, 4));\ntest(\"deliberately wrong\", () => expectEqual(0.1 + 0.2, 0.3));\n"},"solution":{"js":"function expectEqual(actual, expected) {\n if (actual !== expected) {\n throw new Error(`Expected ${expected} but received ${actual}`);\n }\n}\n\nfunction test(name, fn) {\n try {\n fn();\n console.log(`PASS ${name}`);\n } catch (error) {\n console.log(`FAIL ${name}: ${error.message}`);\n }\n}\n\ntest(\"two plus two\", () => expectEqual(2 + 2, 4));\ntest(\"deliberately wrong\", () => expectEqual(0.1 + 0.2, 0.3));\n"},"checks":[{"id":"equal-passes","test":"try { expectEqual(5, 5); expectEqual(\"a\", \"a\"); return true; } catch { return false; }"},{"id":"unequal-throws","test":"try { expectEqual(333, 334); return false; } catch (e) { return e instanceof Error && String(e.message).includes(\"333\") && String(e.message).includes(\"334\"); }"},{"id":"logs-pass","test":"test(\"check-pass-case\", () => expectEqual(1, 1)); return logs.includes(\"PASS check-pass-case\");"},{"id":"logs-fail","test":"test(\"check-fail-case\", () => expectEqual(1, 2)); return logs.some((l) => l.startsWith(\"FAIL check-fail-case\") && l.includes(\"2\"));"},{"id":"keeps-going","test":"try { test(\"check-boom\", () => { throw new Error(\"boom\"); }); } catch { return false; } return logs.some((l) => l.startsWith(\"FAIL check-boom\"));"}],"title":"ابنِ مشغّل اختبارات من عشرة أسطر","prompt":"اكتب الدالتين اللتين يقوم عليهما كل إطار اختبار.
\nexpectEqual(actual, expected) لا تفعل شيئًا حين تكون القيمتان متساويتين تمامًا (===)، وترمي Error في غير ذلك. يجب أن تتضمّن الرسالة القيمتين معًا، مثل Expected 334 but received 333.test(name, fn) تستدعي fn. إن انتهت بشكل طبيعي، اطبع PASS <name>. وإن رمت خطأً، اطبع FAIL <name>: <error message> ولا تُعِد رمي الخطأ، كي يعمل الاختبار التالي.شغّل الكود: الاختبار الثاني يفشل عمدًا، لأن 0.1 + 0.2 لا يساوي 0.3 تمامًا في JavaScript.
expectEqual إلى if واحدة وthrow new Error(...) واحدة. استخدم template literal لوضع القيمتين في الرسالة.","تحتاج test إلى try { … } catch (error) { … } حول استدعاء fn().","اطبع console.log(`PASS ${name}`) بعد fn() داخل try، وconsole.log(`FAIL ${name}: ${error.message}`) داخل catch."],"explanation":"هذا هو قلب Vitest وJest وكل مشغّل اختبارات آخر: الـ assertion عبارة if ترمي خطأً، والاختبار دالة يستدعيها المشغّل داخل try/catch. التقاط الخطأ هو ما يسمح بالإبلاغ عن اختبار فاشل واحد دون إيقاف بقية المجموعة. تضيف الأطر الحقيقية رسائل أفضل (مقارنة الفروق بين الكائنات)، ودعم الكود غير المتزامن، والـ hooks، ووضع المراقبة، والتشغيل المتوازي، لكن العقد هو نفسه: ينجح الاختبار حين تنتهي دالته دون أن ترمي خطأً. ولاحظ أيضًا الفشل المقصود: 0.1 + 0.2 يساوي 0.30000000000000004، وهذا بالضبط سبب تخزين Splitwise-lite للمبالغ كسنتات صحيحة.