{"checkpoints":{"s-tj-1":[{"q":"

يبلّغ مستخدم أن تقسيم عشاء بقيمة $100.00 بين ثلاثة أشخاص يترك الأرصدة منحرفة بسنت واحد. أيّ اختبار تكتبه أولًا؟

","options":[{"text":"اختبار Playwright يضيف العشاء في المتصفّح ويقرأ الأرصدة.","why":"سيعيد إنتاج الخطأ، لكن ببطء ومع تدخّل النظام كله؛ وحين يفشل ما زال عليك أن تجد كود التقريب."},{"text":"اختبار لقطة شاشة لشاشة الأرصدة.","why":"قد تُظهر لقطة الشاشة الرقم الخاطئ لكنها لا تقول شيئًا عن الحساب الذي أنتجه، وتنكسر مع أي تغيير بصري."},{"text":"نوع TypeScript أكثر صرامة لمعامل المبلغ.","why":"القيم أرقام أصلًا؛ ولا يستطيع النوع التمييز بين 3333 و3334 سنتًا."},{"text":"unit test يقسّم 10000 سنت على 3 أشخاص ويتحقّق من أن مجموع الحصص يساوي 10000.","why":"صحيح. الخطأ في منطق صافٍ، فأرخص اختبار يفشل تمامًا حين يكون خاطئًا هو unit test يستغرق جزءًا من الثانية مع ثابت المجموع."}],"answer":3},{"q":"

بافتراض أن الاستيرادات موجودة، ماذا يحدث حين يعمل هذا الاختبار؟

\n
JavaScript
test('formats cents', () => {\n  expect(formatMoney(1234)).toEqual('$12.34');\n  expect(formatMoney(5)).toBe('$0.05');\n});
\n","options":[{"text":"ينجح إن كانت formatMoney صحيحة: فـ toEqual يقارن القيم البدائية بقيمتها، تمامًا مثل toBe.","why":"صحيح. الفرق بين هذين الـ matchers لا يظهر إلا مع الكائنات والمصفوفات."},{"text":"يفشل، لأن toEqual لا يُستخدم إلا مع الكائنات.","why":"يعمل toEqual مع أي قيمة؛ ومع النصوص يتصرّف مثل toBe."},{"text":"يفشل، لأن الاختبار لا يجوز أن يحتوي إلا على expect واحد.","why":"لا توجد قاعدة كهذه؛ سلوك واحد لكل اختبار هو التوجيه، والسطران هنا يفحصان التنسيق."},{"text":"لا يعمل إلا حين يكون globals: true مضبوطًا في الإعدادات.","why":"مع الاستيراد الصريح من vitest، لا حاجة إلى الـ globals."}],"answer":0},{"q":"

في package.json لديك "test": "vitest"، ومهمّة GitHub Actions تشغّل npm test. ماذا يحدث بعد انتهاء الاختبارات في CI؟

","options":[{"text":"تعلق المهمّة في وضع المراقبة حتى تصل إلى مهلة الخادم.","why":"هذا ما كان سيحدث لولا اكتشاف CI؛ فـ Vitest تفحص متغيّر البيئة CI."},{"text":"تخرج Vitest بخطأ تطلب فيه الخيار --run.","why":"لا تشترط Vitest هذا الخيار في CI؛ بل تختار وضع التشغيل الواحد بنفسها."},{"text":"تلاحظ Vitest متغيّر البيئة CI، فتعمل مرة واحدة وتخرج بالنتيجة.","why":"صحيح. وضع المراقبة لا يكون افتراضيًا إلا في طرفية محلية تفاعلية."},{"text":"تتخطّى Vitest الاختبارات لأنه لا توجد طرفية متّصلة.","why":"تعمل الاختبارات بشكل طبيعي في CI؛ والمراقبة وحدها هي التي تُطفأ."}],"answer":2},{"q":"

يفشل اختبار بهذه المخرجات. ما الخطأ الأرجح؟

\n
Text
FAIL  src/tip.test.js > withTip > adds a 15% tip\nAssertionError: expected { tipCents: 300, totalCents: 2000 }\n  to deeply equal { tipCents: 300, totalCents: 2300 }
\n","options":[{"text":"البقشيش يُقرَّب في الاتجاه الخطأ.","why":"قيمة tipCents المستلمة 300، كما هو متوقّع تمامًا، فحساب البقشيش سليم."},{"text":"يجب أن يستخدم الاختبار toBe بدل toEqual.","why":"سيفشل toBe حتى مع نتيجة صحيحة، لأن الدالة تعيد كائنًا جديدًا."},{"text":"النسبة تُقسم على 1000 بدل 100.","why":"عندها سيكون البقشيش 30 لا 300؛ والبقشيش في الكائن المستلم صحيح."},{"text":"المجموع يُعاد دون إضافة البقشيش.","why":"صحيح. totalCents يساوي المجموع الفرعي (2000)، فقد نسيت الدالة إضافة tipCents."}],"answer":3},{"q":"

في مشروعك 300 اختبار لمنطق مالي صافٍ و5 ملفات اختبار تعرض DOM. كيف تضبط البيئة؟

","options":[{"text":"اضبط environment: 'jsdom' على مستوى المشروع كي يستطيع كل اختبار استخدام الـ DOM.","why":"عندها تدفع الاختبارات الصافية الـ 300 كلها ثمن بناء متصفّح مزيّف، ويمرّ الاستخدام غير المقصود للـ DOM في الكود الصافي دون أن يُلاحظ."},{"text":"أبقِ بيئة Node الافتراضية وأضف // @vitest-environment jsdom في أعلى ملفات اختبار الـ DOM الخمسة.","why":"صحيح. فعّل الـ DOM لكل ملف على حدة حيث يُحتاج إليه، وأبقِ البقية سريعة وصادقة."},{"text":"استبدل document بكائن عادي في ملف إعداد.","why":"البديل المصنوع يدويًا يفوته معظم سلوك الـ DOM؛ وjsdom أو happy-dom موجودان بالضبط لتوفيره."},{"text":"انقل اختبارات الـ DOM الخمسة إلى Playwright.","why":"اختبارات الـ end-to-end أبطأ بكثير؛ وسلوك الـ DOM مثل عرض قائمة يخدمه jsdom جيدًا."}],"answer":1}],"s-tj-2":[{"q":"

يمنح Splitwise-lite اشتراكًا مميّزًا مجانيًا للمجموعات التي تنفق $50.00 (5000 سنت) أو أكثر. أيّ مدخلين يختبران القاعدة على أفضل وجه؟

","options":[{"text":"4999 و5000","why":"صحيح. يقعان على جهتي الحدّ، وهما الزوج الوحيد الذي يميّز >= من >."},{"text":"1000 و10000","why":"كلاهما بعيد عن الحدّ، فالخطأ بفارق واحد في المقارنة ينجح فيهما معًا."},{"text":"0 و5000","why":"الصفر حالة إضافية مفيدة، لكن بدون 4999 لا تستطيع معرفة إن كان الحدّ في مكانه الصحيح."},{"text":"5000 و5001","why":"كلاهما يجب أن يستحقّ الاشتراك، فالخطأ الذي يقبل 4999 أيضًا لن يُلتقط."}],"answer":0},{"q":"

ما الذي يجب تغييره في هذا الاختبار؟

\n
JavaScript
test('rejects a negative amount', async () => {\n  expect(saveExpense({ description: 'Taxi', amountCents: -100 }, api))\n    .rejects.toThrow('positive');\n});
\n","options":[{"text":"لا شيء؛ إنه صحيح كما هو مكتوب.","why":"الـ assertion من نوع rejects لا يُنتظَر أبدًا، فلا ينتظره الاختبار؛ وتعلّم Vitest 4 هذه الاختبارات بأنها فاشلة."},{"text":"استبدل toThrow بـ toThrowError.","why":"هما اسمان للشيء نفسه؛ المشكلة في await المفقودة."},{"text":"لفّ الاستدعاء في try/catch وأكّد داخل catch.","why":"هذا لا ينجح إلا مع expect.assertions(1)، وهو أثقل من انتظار rejects."},{"text":"ضع await قبل expect(...) كي ينتظر الاختبار الرفض.","why":"صحيح. كل assertion من نوع resolves أو rejects يجب أن يُنتظَر بـ await."}],"answer":3},{"q":"

أثناء اختبار computeBalances، يستبدل اختبارٌ splitEvenly بـ vi.fn().mockReturnValue([500, 500]). لاحقًا يظهر خطأ تقريب في splitEvenly. ماذا يحدث لذلك الاختبار؟

","options":[{"text":"يفشل، لأن computeBalances تحصل الآن على حصص خاطئة.","why":"لا تستدعي computeBalances الدالة splitEvenly الحقيقية أبدًا في ذلك الاختبار، فلا ترى الخطأ أبدًا."},{"text":"يبقى أخضر، لأن splitEvenly الحقيقية لا تعمل فيه أبدًا.","why":"صحيح. استخدام الـ mocks مكان كودك الصافي يُلغي بالضبط التكامل الذي كان سيلتقط هذا."},{"text":"تحذّر Vitest من أن الـ mock لم يعد يطابق التطبيق الحقيقي.","why":"لا تقارن Vitest الـ mocks بالكود الحقيقي؛ فالـ mock هو ما تقول له أن يكونه."},{"text":"يتعطّل الاختبار لأن الـ mocks للوحدات الداخلية غير مسموح بها.","why":"تسمح بها Vitest، ولهذا يبقى القرار لك."}],"answer":1},{"q":"

يفشل الصف الثاني في هذا الجدول. ما اسم الاختبار الذي تبلّغ عنه Vitest؟

\n
JavaScript
test.each([\n  { total: 1000, people: 3, first: 334 },\n  { total: 1001, people: 4, first: 251 },\n])('splits $total between $people', ({ total, people, first }) => {\n  expect(splitEvenly(total, people)[0]).toBe(first);\n});
\n","options":[{"text":"splits $total between $people","why":"العناصر النائبة $field تُملأ من كائن كل صف."},{"text":"splits 1001 between 4 (row 2)","why":"لا تضيف Vitest رقم الصف ما لم تستخدم %# في الاسم."},{"text":"splits 1001 between 4","why":"صحيح. يصبح كل صف اختبارًا مستقلًّا مع استبدال القيم، فيسمّي الفشل المدخل."},{"text":"splits [object Object] between undefined","why":"يقرأ $total و$people هاتين الخاصيتين من كائن كل صف، فتظهر القيم الحقيقية في الاسم."}],"answer":2},{"q":"

تذكير مجدول بـ setTimeout ليُرسَل بعد 24 ساعة من إضافة مصروف. مع تفعيل vi.useFakeTimers()، أيّ سطر يجعل التذكير يُطلق في الاختبار؟

","options":[{"text":"await new Promise((r) => setTimeout(r, 86_400_000))","why":"مع المؤقّتات المزيّفة يكون setTimeout هذا مزيّفًا أيضًا، فلا يُطلق أبدًا وتنتهي مهلة الاختبار."},{"text":"vi.useRealTimers()","why":"العودة إلى المؤقّتات الحقيقية تعني انتظار يوم حقيقي."},{"text":"vi.setSystemTime(tomorrow)","why":"يحرّك الساعة التي يقرؤها Date، لكنه لا يشغّل المؤقّتات التي حان موعدها."},{"text":"vi.advanceTimersByTime(24 * 60 * 60 * 1000)","why":"صحيح. تقديم الساعة المزيّفة يشغّل فورًا كل مؤقّت يحين موعده خلال تلك الفترة."}],"answer":3}],"s-tj-3":[{"q":"

يعرض النموذج أخطاء التحقّق في <p role="alert">Amount must be greater than zero</p>. أيّ query هو الأنسب؟

","options":[{"text":"screen.getByRole('alert')","why":"صحيح. الدور هو ما تعلنه قارئات الشاشة، فيفشل الاختبار إن توقّف إعلان الرسالة."},{"text":"container.querySelector('.error-text')","why":"الصنف تنسيق؛ وإعادة تسميته تكسر الاختبار دون أن تكسر شيئًا يراه المستخدمون."},{"text":"screen.getByTestId('amount-error')","why":"الـ test ids هي الملاذ الأخير، ولا تثبت شيئًا عن طريقة وصول الرسالة إلى المستخدمين."},{"text":"screen.getByDisplayValue('Amount must be greater than zero')","why":"استعلامات display value تطابق القيمة الحالية لحقول النماذج، لا نص الفقرات."}],"answer":0},{"q":"

يُحلّ load بالقيمة { Ben: -500 }. يفشل هذا الاختبار بالرسالة “Unable to find an element with the text”. ما الإصلاح؟

\n
JSX
test('shows balances', () => {\n  render(<BalancePanel loadBalances={load} />);\n  expect(screen.getByText('Ben owes $5.00')).toBeInTheDocument();\n});
\n","options":[{"text":"لفّ render داخل waitFor.","why":"يعيد waitFor محاولة الـ assertions؛ وتكرار الـ render داخله لا يفيد ويسبّب آثارًا جانبية."},{"text":"ارفع مهلة الاختبار في Vitest.","why":"يفشل الاختبار فورًا، لا بعد انتهاء مهلة: يفحص getByText مرة واحدة، قبل أن يُحلّ الـ promise."},{"text":"اجعل الاختبار async واستخدم expect(await screen.findByText('Ben owes $5.00')).toBeInTheDocument().","why":"صحيح. ينتظر findByText ظهور النص بعد تحميل البيانات."},{"text":"استخدم screen.queryByText('Ben owes $5.00') بدلًا من ذلك.","why":"يفحص queryBy أيضًا مرة واحدة فقط؛ سيعيد null ويظلّ الـ assertion يفشل."}],"answer":2},{"q":"

تستخدم اختبارات المكوّنات MSW مع server.listen({ onUnhandledRequest: 'error' }). إعادة هيكلة تغيّر عن غير قصد الـ URL في الطلب من /groups/:id إلى /group/:id. ماذا يحدث؟

","options":[{"text":"تنجح الاختبارات، لأن MSW يجيب عن كل طلب بـ 200 فارغ.","why":"لا يجيب MSW إلا عن الطلبات التي تطابق معالِجًا؛ وليس لديه استجابة نجاح شاملة."},{"text":"تفشل الاختبارات، لأن الطلب لا يطابق أي معالِج، والطلبات غير المعالَجة أخطاء.","why":"صحيح. هذا الخيار يحوّل الـ URL الخاطئ إلى فشل صاخب بدل تعليق صامت أو استدعاء شبكة حقيقي."},{"text":"يمرّر MSW الطلب بصمت إلى الشبكة الحقيقية.","why":"مع onUnhandledRequest: 'error'، يُبلَّغ عن الطلبات غير المطابقة كأخطاء، ولا تُمرَّر بهدوء."},{"text":"تتخطّى Vitest الاختبارات المتأثّرة.","why":"لا شيء يُتخطّى؛ الطلب الفاشل يظهر على شكل فشل في الاختبار."}],"answer":1},{"q":"

أيّ استخدام لـ waitFor مناسب؟

","options":[{"text":"await waitFor(() => user.click(screen.getByRole('button', { name: 'Save' })))","why":"النقر داخل دالة يُعاد تشغيلها قد يحدث عدة مرات؛ والتفاعلات مكانها خارج waitFor."},{"text":"await waitFor(() => screen.findByText('Saved'))","why":"ينتظر findBy أصلًا؛ ولفّه داخل waitFor يضاعف الانتظار ويُربك المهلة."},{"text":"await waitFor(() => {})","why":"الدالة الفارغة تنجح فورًا ولا تنتظر شيئًا بعينه."},{"text":"await waitFor(() => expect(onSave).toHaveBeenCalledTimes(1))","why":"صحيح. assertion لا يتعلّق بظهور عنصر، يُعاد حتى يتحقّق."}],"answer":3},{"q":"

في ExpenseList مربّع اختيار “Hide settled”. ما أفضل اختبار له؟

","options":[{"text":"انقر مربّع الاختيار بـ user-event وأكّد أيّ عناصر القائمة ما زالت على الشاشة.","why":"صحيح. يختبر ما يراه المستخدم، ويصمد أمام أي تغيير في طريقة تخزين الـ state."},{"text":"أكّد أن useState استُدعي بالقيمة false في البداية.","why":"هذا يفحص الأجزاء الداخلية لـ React، لا السلوك؛ وقد تظلّ القائمة تُعرض بشكل خاطئ."},{"text":"التقط snapshot قبل النقر وبعده.","why":"الـ snapshots تسجّل كل شيء ولا تشرح شيئًا؛ ولا يستطيع المراجعون معرفة ما الذي كان يجب أن يتغيّر."},{"text":"استدعِ المكوّن كدالة وافحص الـ JSX المُعاد.","why":"استدعاء المكوّنات مباشرة يتخطّى الـ render في React وقواعد الـ hooks؛ اعرضه بالـ render بدلًا من ذلك."}],"answer":0}],"s-tj-4":[{"q":"

حقل المبلغ هو <label for="amount">Amount</label><input id="amount" name="amount" placeholder="0.00">. أيّ locator في Playwright هو الأفضل؟

","options":[{"text":"page.locator('input[name=amount]')","why":"يعمل، لكنه يعتمد على خاصية لا يراها المستخدمون أبدًا ولا يفحص شيئًا عن التسمية."},{"text":"page.getByPlaceholder('0.00')","why":"النصوص النائبة إشارة أضعف من التسميات، وكثيرًا ما تتغيّر أو تختفي."},{"text":"page.getByLabel('Amount')","why":"صحيح. يجد الحقل بتسميته، بالطريقة التي يجده بها المستخدمون والتقنيات المساعدة."},{"text":"page.locator('#amount')","why":"المعرّفات تفاصيل داخلية قد تتغيّر في إعادة هيكلة."}],"answer":2},{"q":"

يستغرق تسجيل الدخول 3 ثوانٍ. أربعون اختبارًا تحتاج إلى مستخدم مسجّل الدخول لكنها لا تغيّر الحساب أبدًا. ما أفضل نهج؟

","options":[{"text":"سجّل الدخول عبر الواجهة داخل beforeEach.","why":"هذا يضيف دقيقتين من تسجيلات الدخول ويُرهق خدمة المصادقة دون أي ثقة إضافية."},{"text":"دع اختبارًا واحدًا يسجّل الدخول وشغّل البقية بعده في الوضع التسلسلي.","why":"الاختبارات المتسلسلة لا يمكن تشغيلها بالتوازي ولا منفردة، وفشل واحد يتتالى."},{"text":"شارك كائن page واحدًا بين كل الاختبارات في متغيّر على مستوى الوحدة.","why":"مشاركة الصفحة تكسر العزل؛ فقد يترك اختبار حالة تغيّر اختبارًا آخر."},{"text":"سجّل الدخول مرة واحدة في setup project، واحفظ حالة التخزين، ودع الاختبارات تعيد استخدامها.","why":"صحيح. ما زال كل اختبار يحصل على سياقه الخاص، مصادَقًا عليه مسبقًا."}],"answer":3},{"q":"

في trace لاختبار فاشل، نجح النقر على “Settle up”، ولقطة الـ DOM بعده مباشرة تُظهر رسالة منبثقة “Session expired, please sign in”. ما الذي تحقّق فيه أولًا؟

","options":[{"text":"إعداد المصادقة في الاختبار، مثل حالة تخزين محفوظة منتهية الصلاحية.","why":"صحيح. استجابت الصفحة فعلًا؛ لكنها رفضت الجلسة، فالمشكلة في طريقة تسجيل الاختبار للدخول."},{"text":"إضافة page.waitForTimeout(2000) قبل الـ assertion.","why":"الانتظار أطول لن يحيي جلسة منتهية."},{"text":"تغيير الـ locator الخاص بـ Settle up.","why":"يُظهر الـ trace أن النقر أصاب الزر الصحيح."},{"text":"ترقية Playwright، لأن هذا يبدو خطأً في الأداة.","why":"تُظهر اللقطة أن التطبيق يتصرّف بشكل صحيح مع جلسة منتهية؛ والمشتبه به هو إعداد الاختبار."}],"answer":0},{"q":"

تريد اختبار أن صفحة المجموعة تعرض “Could not load this group” حين يجيب الـ API بـ 503. ماذا تفعل؟

","options":[{"text":"أوقف خادم الـ backend في CI قبل تشغيل ذلك الاختبار.","why":"هذا يكسر كل اختبار آخر يعمل بالتوازي على الخادم نفسه."},{"text":"استدعِ page.route('**/api/groups/*', (route) => route.fulfill({ status: 503 })) قبل page.goto.","why":"صحيح. يُنتج التوجيه الاستجابة النادرة لهذا الاختبار وحده دون لمس الخادم الحقيقي."},{"text":"استبدل fetch بـ vi.fn() داخل اختبار Playwright.","why":"vi تابع لـ Vitest؛ واختبارات Playwright تعمل في Node بينما تعمل الصفحة في متصفّح حقيقي."},{"text":"ارمِ خطأً داخل hook من نوع beforeEach.","why":"هذا يُفشل الاختبار قبل أن يبدأ بدل أن يحاكي استجابة الخادم."}],"answer":1},{"q":"

ينجح اختبار دائمًا مع --workers=1 ويفشل أحيانًا مع --workers=4. ما المشتبه به الأول؟

","options":[{"text":"مهل أقصر من اللازم للتشغيل المتوازي.","why":"ممكن، لكن السبب الكلاسيكي للحساسية تجاه الترتيب والتوازي هو الحالة المشتركة."},{"text":"عدم تطابق إصدارات المتصفّح بين العمّال.","why":"يستخدم كل العمّال المتصفّحات المثبّتة نفسها."},{"text":"اختبارات تتشارك البيانات على الخادم، فتغيّر الاختبارات المتوازية ما يراه غيرها.","why":"صحيح. أعطِ كل اختبار بياناته الخاصة، مثلًا عبر fixture بأسماء فريدة."},{"text":"assertions كثيرة جدًا في اختبار واحد.","why":"عدد الـ assertions لا يتفاعل مع عدد العمّال."}],"answer":2}],"s-tj-5":[{"q":"

بكتابة الاختبار أولًا، لديك parseAmount('12') ينجح مع return Number(input) * 100;. أيّ اختبار تالٍ يفرض أصغر خطوة مفيدة؟

","options":[{"text":"جدول من 500 صف بكل صيغة تخطر لك.","why":"كتابة اختبارات كثيرة دفعة واحدة تفرض قفزة كبيرة؛ والـ TDD يتقدّم باختبار فاشل صغير واحد في كل مرة."},{"text":"expect(() => parseAmount('abc')).toThrow()","why":"صحيح. يفشل اليوم (فالكود يعيد NaN) ويحتاج إلى تغيير صغير واحد: رفض ما ليس رقمًا."},{"text":"expect(parseAmount('12')).toBe(1200) باسم مختلف.","why":"ينجح أصلًا، فلا يفرض شيئًا جديدًا."},{"text":"اختبار Playwright لنموذج المصروفات كاملًا.","why":"خطوة أكبر بكثير من اللازم، وتغذية راجعة بطيئة لقاعدة تحليل."}],"answer":1},{"q":"

الملف src/money/settle-up.js بلا اختبارات، لكنه لا يظهر في تقرير الـ coverage في Vitest أصلًا. لماذا؟

","options":[{"text":"لا يستطيع المزوّد v8 قياس ذلك الملف.","why":"يقيس v8 أي JavaScript تحمّله الاختبارات؛ وهذا الملف لم يُحمَّل قط."},{"text":"الملف مغطّى بالكامل، فهو مخفي.","why":"الملفات المغطّاة تُسرد أيضًا؛ ولا شيء يُخفيها."},{"text":"الحدود الدنيا للـ coverage تستبعد الملفات التي دون الحدّ.","why":"الحدود الدنيا تُفشل التشغيل؛ ولا تزيل الملفات من التقرير."},{"text":"coverage.include غير مضبوط، فلا يُبلَّغ إلا عن الملفات التي حمّلتها الاختبارات.","why":"صحيح. اضبط include (مثلًا src/**/*.js) كي تظهر الملفات غير المختبَرة بنسبة 0%."}],"answer":3},{"q":"

يبلّغ Stryker عن EqualityOperator: amountCents <= 0 → amountCents < 0 بأنه Survived في التحقّق داخل saveExpense. أيّ اختبار يقتله؟

","options":[{"text":"حفظ مصروف بقيمة amountCents: 0 يجب أن يُرفض.","why":"صحيح. الصفر هو القيمة الوحيدة التي يختلف عندها <= 0 عن < 0."},{"text":"حفظ مصروف بقيمة amountCents: -100 يجب أن يُرفض.","why":"كلتا النسختين ترفضان -100، فينجو الـ mutant."},{"text":"حفظ مصروف بقيمة amountCents: 4500 يجب أن يُحلّ بنجاح.","why":"كلتا النسختين تقبلان 4500، فينجو الـ mutant من هذا الاختبار."},{"text":"حفظ مصروف بقيمة amountCents: 12.5 يجب أن يُرفض.","why":"فحص العدد الصحيح يرفض 12.5 في النسختين."}],"answer":0},{"q":"

في workflow GitHub Actions، يختفي artifact تقرير Playwright في كل مرة تفشل فيها الاختبارات. ما الذي ينقص خطوة الرفع؟

","options":[{"text":"needs: e2e","why":"يرتّب needs المهامّ؛ والمشكلة في خطوة تُتخطّى داخل المهمّة نفسها."},{"text":"retention-days: 30","why":"مدة الاحتفاظ تتحكّم في المدة التي يُحفظ فيها الـ artifact، لا في رفعه من عدمه."},{"text":"if: ${{ !cancelled() }}، كي تعمل حتى بعد فشل خطوة الاختبار.","why":"صحيح. تُتخطّى الخطوات بعد الفشل افتراضيًا؛ والشرط يجعل الرفع يعمل رغم ذلك."},{"text":"--shard=1/1 في أمر الاختبار.","why":"الـ sharding يقسّم المجموعة؛ ولا علاقة له برفع التقارير."}],"answer":2},{"q":"

أيّ من هذه الاختبارات يستحق أن يُكتب؟

","options":[{"text":"أن sortBy في lodash يرتّب المصروفات حسب التاريخ.","why":"هذا يختبر المكتبة، وهو ما يفعله القائمون على صيانتها أصلًا."},{"text":"أن رسالة الخطأ تحمل الصنف text-red-600.","why":"تفاصيل التنسيق تجعل الاختبارات هشّة دون أن تلتقط أخطاء السلوك."},{"text":"أن دالة مساعدة خاصة تُستدعى مرتين بالضبط.","why":"يجمّد التفاصيل الداخلية وينجح مع الأخطاء الحقيقية."},{"text":"أن السنت المتبقّي الواحد يذهب إلى أول شخص في التقسيم.","why":"صحيح. إنه سلوك مالي موثّق قد يكسره خطأ معقول."}],"answer":3}]},"final":[{"q":"

نموذج يحلّل المبلغ ويرسله عبر عميل API. أيّ اختبار يعطي أكبر ثقة مقابل كل دقيقة من CI لذلك النموذج؟

","options":[{"text":"اختبار مكوّن يعرض النموذج مع المحلّل الحقيقي وشبكة مزيّفة.","why":"صحيح. يشغّل النموذج والتحليل والطلب معًا، في أجزاء من الثانية، دون متصفّح أو خادم."},{"text":"unit test لعميل الـ API وحده.","why":"مفيد، لكنه لا يقول شيئًا عمّا إذا كان النموذج يستخدم المحلّل والعميل بشكل صحيح."},{"text":"اختبار end-to-end لكل رسالة تحقّق.","why":"فحص كل رسالة أرخص وأدقّ على مستوى المكوّن؛ واحتفظ بالـ end-to-end للمسار الرئيسي."},{"text":"أنواع TypeScript أكثر صرامة على الـ props الخاصة بالنموذج.","why":"تلتقط الأنواع أخطاء الشكل، لا إن كانت 12.5 تصبح 1250 سنتًا."}],"answer":0},{"q":"

ما المشكلة الأساسية في هذا الاختبار؟

\n
JavaScript
test('withTip', () => {\n  expect(withTip(2000, 15).tipCents).toBe(300);\n  expect(() => withTip(2000, -1)).toThrow();\n  expect(withTip(2000, 0).totalCents).toBe(2000);\n});
\n","options":[{"text":"لا يستطيع toBe مقارنة الأرقام بشكل موثوق.","why":"مع أعداد صحيحة كهذه، يكون toBe هو الصحيح تمامًا."},{"text":"يفحص ثلاثة سلوكيات، ففشل الأول يُخفي البقية، والاسم لا يقول ما الذي انكسر.","why":"صحيح. قسّمه إلى ثلاثة اختبارات تحمل أسماء القواعد التي تفحصها."},{"text":"لا يجوز أن يحتوي الاختبار إلا على استدعاء expect واحد.","why":"عدة assertions عن سلوك واحد مقبولة؛ المشكلة في السلوكيات الثلاثة."},{"text":"يجب انتظار withTip بـ await.","why":"withTip متزامنة؛ ولا يوجد ما يُنتظر."}],"answer":1},{"q":"

يجب أن يكون عدد أعضاء المجموعة بين 2 و12. أيّ المدخلات تختبر القاعدة على أفضل وجه؟

","options":[{"text":"5 و6 و7","why":"كلها في منتصف النطاق الصالح؛ وأخطاء الحدود تنجح فيها جميعًا."},{"text":"2 و12","why":"تختبر الحافّتين الصالحتين لكنها لا تختبر الجهة غير الصالحة من أيّ حدّ."},{"text":"0 و100","why":"بعيدة عن الحدّين، فلن يُلاحظ خطأ بفارق واحد."},{"text":"1 و2 و12 و13","why":"صحيح. خارج كل حدّ مباشرة، وعليه."}],"answer":3},{"q":"

ينجح await expect(loadGroup('x', fetchMock)).rejects.toThrow() مع الكود الصحيح ومع نسخة تنهار بخطأ TypeError قبل أن تفحص رمز الحالة. كيف تجعل الاختبار ذا معنى؟

","options":[{"text":"استخدم resolves بدل rejects.","why":"يجب أن يُرفض الـ promise؛ والانتقال إلى resolves سيجعل الكود الصحيح يفشل."},{"text":"أضف مزيدًا من كلمات await حول الاستدعاء.","why":"الـ assertion منتظَر أصلًا؛ وما ينقص هو الدقّة."},{"text":"طابق الرسالة المتوقّعة، مثلًا .rejects.toThrow('HTTP 404').","why":"صحيح. لا تُنتج تلك الرسالة إلا النسخة التي تفحص رمز الحالة فعلًا."},{"text":"استبدل toThrow بـ toThrowError.","why":"هما اسمان لسلوك متطابق."}],"answer":2},{"q":"

تنجح الاختبارات واحدًا واحدًا لكنها تفشل في التشغيل الكامل. اختبار سابق ينفّذ vi.spyOn(Math, 'random').mockReturnValue(0). ما الإصلاح؟

","options":[{"text":"استعِد الـ mocks بعد كل اختبار، بـ vi.restoreAllMocks() داخل afterEach أو بـ restoreMocks: true في الإعدادات.","why":"صحيح. استبدل الـ spy دالة على كائن مشترك وتسرّب إلى الاختبارات اللاحقة."},{"text":"شغّل ملفات الاختبار واحدًا تلو الآخر.","why":"هذا يُخفي التسرّب بدل أن يزيله، ويجعل المجموعة أبطأ."},{"text":"ارفع مهلة الاختبار في Vitest.","why":"حالات الفشل تتعلّق بحالة متسرّبة، لا بالوقت."},{"text":"توقّف عن استخدام Math.random في كود الإنتاج.","why":"كود الإنتاج سليم؛ الاختبار هو الذي نسي أن ينظّف بعد نفسه."}],"answer":0},{"q":"

زرّ أيقونة فقط يُعرض هكذا: <button aria-label="Delete expense"><svg>…</svg></button>. أيّ query يجب أن يستخدمه اختبار Testing Library؟

","options":[{"text":"screen.getByText('Delete expense')","why":"لا يوجد نص ظاهر؛ فالاسم يأتي من aria-label، ولا تقرؤه استعلامات النص."},{"text":"screen.getByRole('button', { name: 'Delete expense' })","why":"صحيح. الاسم القابل للوصول يأتي من aria-label، فيجده استعلام الدور كما يجده قارئ الشاشة."},{"text":"screen.getByTestId('delete')","why":"هناك اسم قابل للوصول جيد تمامًا؛ والـ test id سيكون خطوة إلى الوراء."},{"text":"container.querySelector('svg').closest('button')","why":"يربط الاختبار ببنية الأيقونة ويتجاهل الاسم القابل للوصول."}],"answer":1},{"q":"

تظهر رسالة منبثقة “Saved” بعد الحفظ وتختفي بعد لحظة. كيف تؤكّد أنها تختفي؟

","options":[{"text":"expect(screen.getByText('Saved')).toBeNull()","why":"يرمي getByText خطأً ما دامت الرسالة موجودة، ولا يعيد null أبدًا."},{"text":"expect(await screen.findByText('Saved')).toBeNull()","why":"يُحلّ findByText بالعنصر حين يظهر؛ ولا يُحلّ أبدًا بـ null."},{"text":"انتظر 5 ثوانٍ، ثم expect(screen.queryByText('Saved')).toBeNull()","why":"الانتظار الثابت بطيء ويظلّ يتسابق على جهاز مشغول."},{"text":"await waitForElementToBeRemoved(() => screen.queryByText('Saved'))","why":"صحيح. ينتظر بالضبط حتى تختفي الرسالة، أو يفشل بعد انتهاء المهلة."}],"answer":3},{"q":"

يفشل هذا الفحص في Playwright بين حين وآخر في CI. ما الإصلاح؟

\n
TypeScript
const rows = await page.getByRole('listitem').all();\nexpect(rows.length).toBe(3);
\n","options":[{"text":"أضف await page.waitForLoadState('networkidle') قبله.","why":"هدوء الشبكة مؤشّر ضعيف على عرض القائمة، والـ assertion ما زال لا يعيد المحاولة."},{"text":"استخدم await page.getByRole('listitem').count() بدل .all().","why":"ما زالت قراءة لمرة واحدة يتبعها assertion لا يعيد المحاولة."},{"text":"await expect(page.getByRole('listitem')).toHaveCount(3)","why":"صحيح. يعيد الـ assertion الموجّه للويب العدّ حتى تصبح العناصر ثلاثة أو تنتهي المهلة."},{"text":"اضبط retries: 3 في الإعدادات.","why":"إعادة المحاولة تُخفي السباق بدل أن تصلحه."}],"answer":2},{"q":"

تتشارك اختبارات الـ end-to-end مجموعة واحدة معبّأة مسبقًا، وأحدها يحذف منها مصروفًا. تفشل اختبارات أخرى حسب الترتيب. ما الإصلاح الأفضل؟

","options":[{"text":"fixture تنشئ مجموعة باسم فريد لكل اختبار عبر الـ API وتحذفها بعده.","why":"صحيح. كل اختبار يملك بياناته، فيتوقّف الترتيب والتوازي عن أن يكونا مهمّين."},{"text":"شغّل المجموعة تسلسليًا بترتيب ثابت.","why":"يُخفي الاعتماد، ويبطّئ المجموعة، ويدع فشلًا واحدًا يتتالى."},{"text":"أعد تعبئة قاعدة البيانات مرة واحدة قبل المجموعة كلها.","why":"ما زالت الاختبارات تتشارك البيانات نفسها وتغيّرها أثناء التشغيل."},{"text":"فعّل ثلاث محاولات إعادة لتلك الاختبارات.","why":"إعادة المحاولة تحجب التصادم دون أن تزيله."}],"answer":0},{"q":"

أيّ أداة تخبرك أن لا اختبار سيلاحظ لو أصبح < في كودك <=؟

","options":[{"text":"تغطية الأسطر","why":"لا تُظهر تغطية الأسطر إلا أن السطر عمل."},{"text":"تغطية الفروع","why":"تُظهر تغطية الفروع أن جهتي الشرط عملتا، لا أن اختبارًا سيفشل لو تحرّك الحدّ."},{"text":"مترجم TypeScript","why":"لـ < و<= الأنواع نفسها؛ ولا يستطيع المترجم التمييز بينهما."},{"text":"الـ mutation testing، مثل StrykerJS","why":"صحيح. يُجري هذا التغيير بالضبط ويبلّغ إن فشل أيّ اختبار."}],"answer":3},{"q":"

ما زالت الـ pull requests تُدمج بينما مهمّة الـ end-to-end حمراء. ما الإصلاح الصحيح؟

","options":[{"text":"أعد تشغيل المهمّة حتى تخضرّ، ثم ادمج.","why":"هذا يدرّب الناس على تجاهل حالات الفشل، بما فيها الحقيقية."},{"text":"اجعل مهامّ الاختبار فحوص حالة إلزامية على الفرع الرئيسي.","why":"صحيح. الفحص الإلزامي الأحمر يمنع الـ merge، فيصبح الـ pipeline بوابة لا اقتراحًا."},{"text":"أزل مهمّة الـ end-to-end كي يبقى الـ pipeline أخضر.","why":"هذا يرمي الفحص الوحيد الذي يتحقّق من أن القطع تعمل معًا."},{"text":"شغّل مهمّة الـ end-to-end بعد الـ merge فقط.","why":"عندها يصل الكود المعطوب إلى main قبل أن يعلم به أحد."}],"answer":1},{"q":"

اختبار مكوّن يستخدم mock مكان formatMoney الصافية الخاصة بك بحيث تعيد دائمًا 'X'. ما التغيير الأفضل؟

","options":[{"text":"أبقِ الـ mock وأضف snapshot للمخرجات.","why":"سيسجّل الـ snapshot القيمة X ولن يختبر التنسيق الحقيقي أبدًا."},{"text":"استبدل الـ mock بـ vi.mock على الوحدة.","why":"الفكرة نفسها بأداة مختلفة؛ والدالة الحقيقية ما زالت لا تعمل أبدًا."},{"text":"استخدم formatMoney الحقيقية: إنها كود صافٍ سريع تملكه، والاختبار عندها يفحص المخرجات الحقيقية.","why":"صحيح. استخدم الـ mocks عند الحدود؛ وشغّل منطقك الصافي على حقيقته."},{"text":"احذف اختبار المكوّن.","why":"ما زال المكوّن يحتاج إلى اختبار؛ وكل ما عليه هو التوقّف عن تزييف دالة التنسيق."}],"answer":2}],"glossary":[{"id":"testing-trophy","term":"كأس الاختبارات (Testing trophy)","definition":"نموذج لمجموعة الاختبارات من أربع طبقات: التحليل الساكن، واختبارات unit وintegration وend-to-end. يكون في أعرض حالاته عند اختبارات الـ integration، التي تمنح عادةً أكبر ثقة مقابل تكلفتها.","lesson":"l-tj-1-1"},{"id":"unit-test","term":"Unit test","definition":"اختبار يفحص دالة واحدة أو وحدة برمجية واحدة بمعزل عن غيرها، وعادةً في أجزاء من الثانية. مثالي للمنطق الصافي ذي الحالات الحدّية الكثيرة، مثل تقريب المبالغ المالية.","lesson":"l-tj-1-1"},{"id":"integration-test","term":"Integration test","definition":"اختبار يفحص عدة وحدات تعمل معًا، مثل مكوّن نموذج يستخدم كود التحليل الحقيقي مع شبكة مزيّفة. يلتقط أخطاء الربط التي تفوت الـ unit tests.","lesson":"l-tj-1-1"},{"id":"end-to-end-test","term":"End-to-end test","definition":"اختبار يقود التطبيق الحقيقي في متصفّح حقيقي، عبر الواجهة والـ API وطبقة البيانات. وهو أقرب أنواع الاختبارات إلى الواقع وأغلاها ثمنًا.","lesson":"l-tj-4-1"},{"id":"watch-mode","term":"وضع المراقبة (Watch mode)","definition":"الوضع الافتراضي لـ Vitest محليًا: بعد التشغيل ينتظر، وحين تحفظ ملفًا يعيد تشغيل الاختبارات المتأثّرة بذلك التغيير فقط، معتمدًا على مخطّط الوحدات في Vite.","lesson":"l-tj-1-2"},{"id":"aaa","term":"Arrange, Act, Assert","definition":"شكل ثلاثي للاختبارات: ابنِ المدخلات، ونفّذ الفعل الوحيد الخاضع للاختبار، ثم اذكر ما يجب أن يكون صحيحًا الآن. يجعل الاختبارات سهلة التصفّح بالعين.","lesson":"l-tj-1-3"},{"id":"assertion","term":"Assertion","definition":"فحص داخل الاختبار يرمي خطأً حين لا تكون القيمة كما توقّعت، مثل expect(total).toBe(1000). ويفشل الاختبار حين يرمي أحد الـ assertions خطأً.","lesson":"l-tj-1-3"},{"id":"implementation-detail","term":"التفاصيل الداخلية (Implementation detail)","definition":"الطريقة التي ينتج بها الكود نتيجته (دوال مساعدة خاصة، وحالة داخلية، وترتيب الاستدعاءات)، في مقابل السلوك الذي يلاحظه المستدعون. الاختبارات المرتبطة بها تنكسر مع إعادات هيكلة غير ضارّة.","lesson":"l-tj-2-1"},{"id":"invariant","term":"الثابت (Invariant)","definition":"خاصية تصحّ مع كل مدخل صالح، مثل “مجموع الحصص يساوي الإجمالي”. وتأكيد ثابت ما عبر عدة مدخلات يلتقط عائلات كاملة من الأخطاء.","lesson":"l-tj-2-1"},{"id":"boundary-value","term":"تحليل القيم الحدّية (Boundary value analysis)","definition":"اختبار المدخلات الواقعة تحت كل حدّ في قاعدة ما مباشرة، وعليه، وفوقه مباشرة، مثل 0 و0.01، أو منزلتين عشريتين وثلاث، لأن الأخطاء تتجمّع عند هذه الحواف.","lesson":"l-tj-2-2"},{"id":"table-driven-test","term":"الاختبار المعتمد على الجداول (Table-driven test)","definition":"اختبار يُكتب مرة واحدة ويُشغَّل لكل صف في جدول من المدخلات والمخرجات المتوقّعة. في Vitest، ينشئ test.each اختبارًا مسمّى لكل صف.","lesson":"l-tj-2-2"},{"id":"stub","term":"Stub","definition":"متعاون بديل يعيد إجابات جاهزة كي يتحكّم الاختبار في اعتمادية ما، مثل كائن API تُحلّ دالة post فيه دائمًا بمعرّف.","lesson":"l-tj-2-3"},{"id":"test-double","term":"بديل الاختبار (Test double)","definition":"أي شيء يقوم مقام متعاون حقيقي في الاختبار: الـ stubs تعيد إجابات جاهزة، والـ spies تسجّل الاستدعاءات، والـ mocks هي spies تؤكّد عليها، والـ fakes نسخ أبسط تعمل فعلًا.","lesson":"l-tj-2-4"},{"id":"spy","term":"Spy","definition":"غلاف حول دالة يسجّل كيف استُدعيت. يراقب vi.spyOn(object, method) دالة حقيقية، ويستطيع أيضًا استبدالها إلى أن تُستعاد.","lesson":"l-tj-2-4"},{"id":"fake-timers","term":"المؤقّتات المزيّفة (Fake timers)","definition":"ساعة خاصة بالاختبار تستبدل setTimeout وsetInterval وDate، فتستطيع الاختبارات القفز إلى الأمام باستدعاءات مثل vi.advanceTimersByTime(2000) بدل الانتظار بالوقت الحقيقي.","lesson":"l-tj-2-4"},{"id":"accessible-name","term":"الاسم القابل للوصول (Accessible name)","definition":"الاسم الذي تعلنه التقنيات المساعدة لعنصر ما، ويُحسب من aria-labelledby أو aria-label أو تسمية مرتبطة أو نص العنصر. وتطابق استعلامات الدور عليه.","lesson":"l-tj-3-1"},{"id":"query-priority","term":"أولوية الاستعلامات (Query priority)","definition":"الترتيب الذي توصي به Testing Library لإيجاد العناصر: بالدور، أو التسمية، أو النص النائب، أو النص، أو القيمة المعروضة أولًا؛ ثم النص البديل والعنوان؛ والـ test ids في الأخير.","lesson":"l-tj-3-1"},{"id":"user-event","term":"user-event","definition":"حزمة من Testing Library تحاكي تفاعلات المستخدم كاملة، بما فيها أحداث المؤشّر والتركيز ولوحة المفاتيح، بدل إطلاق أحداث منفردة كما يفعل fireEvent.","lesson":"l-tj-3-2"},{"id":"findby","term":"استعلام findBy (findBy query)","definition":"استعلام غير متزامن في Testing Library يعيد المحاولة حتى يظهر عنصر مطابق، فيُحلّ به، أو يُرفض بعد انتهاء المهلة (ثانية واحدة افتراضيًا).","lesson":"l-tj-3-3"},{"id":"msw","term":"MSW (Mock Service Worker)","definition":"مكتبة تعترض طلبات الشبكة في Node والمتصفّح وتجيب عنها بمعالِجات تعرّفها أنت، فيظلّ الـ fetch الحقيقي وكود البيانات لديك يعملان في الاختبارات.","lesson":"l-tj-3-4"},{"id":"locator","term":"Locator","definition":"في Playwright، وصف كسول وصارم لطريقة إيجاد عنصر، مثل page.getByRole('button', { name: 'Save' }). ويُعاد حلّه مع كل فعل.","lesson":"l-tj-4-1"},{"id":"web-first-assertion","term":"Assertion موجّه للويب (Web-first assertion)","definition":"assertion في Playwright على locator، مثل toHaveText، يعيد فحص الصفحة حتى ينجح أو تنتهي مهلته، بدل قراءة قيمة مرة واحدة.","lesson":"l-tj-4-1"},{"id":"fixture","term":"Fixture","definition":"في Playwright، قيمة يطلبها الاختبار باسمها، مثل page أو group مخصّصة، تُهيّأ قبل use() وتُهدم بعده، ولا تُنشأ إلا للاختبارات التي تحتاجها.","lesson":"l-tj-4-2"},{"id":"trace","term":"Trace","definition":"تسجيل من Playwright لتشغيل اختبار، فيه كل فعل، ولقطات DOM قبله وبعده، ومخرجات الـ console، واستدعاءات الشبكة، ويُفتح في عارض الـ trace.","lesson":"l-tj-4-3"},{"id":"flaky-test","term":"Flaky test","definition":"اختبار متقلّب ينجح أحيانًا ويفشل أحيانًا دون أي تغيير في الكود، عادةً بسبب التوقيت أو البيانات المشتركة أو الوقت غير المتحكَّم فيه. ويعلّم الفرق تجاهل حالات الفشل.","lesson":"l-tj-4-3"},{"id":"tdd","term":"التطوير الموجّه بالاختبارات (TDD)","definition":"كتابة اختبار فاشل واحد، ثم جعله ينجح بأبسط كود، ثم إعادة الهيكلة والاختبارات خضراء، في دورات قصيرة متكرّرة تُعرف بـ red وgreen وrefactor.","lesson":"l-tj-5-1"},{"id":"code-coverage","term":"Code coverage","definition":"نسبة العبارات والفروع والدوال والأسطر التي عملت أثناء الاختبارات. تُظهر الكود غير المختبَر، لكنها لا تُظهر إن كان الكود المنفَّذ قد فُحص فعلًا.","lesson":"l-tj-5-2"},{"id":"mutation-testing","term":"اختبار الطفرات (Mutation testing)","definition":"تقييم مجموعة الاختبارات بصنع أخطاء صغيرة متعمَّدة (mutants) في الكود وإعادة تشغيل الاختبارات؛ الـ mutants المقتولة التُقطت، والناجية تكشف اختبارات ضعيفة.","lesson":"l-tj-5-3"},{"id":"equivalent-mutant","term":"Mutant متكافئ (Equivalent mutant)","definition":"mutant لا يغيّر تعديله أي سلوك يستطيع المستدعي ملاحظته، فلا يستطيع أي اختبار معقول قتله. يجب تجاهله، لا مطاردته.","lesson":"l-tj-5-3"},{"id":"required-check","term":"فحص الحالة الإلزامي (Required status check)","definition":"مهمّة CI يجب أن تنجح قبل أن يُدمج pull request في فرع محمي، فتحوّل pipeline الاختبارات من اقتراح إلى بوابة.","lesson":"l-tj-5-4"}]}