دليل شامل لاختبار وحدات الواجهة الأمامية باستخدام Jest

عندما تبدأ في أخذ تطوير واجهات المستخدم على محمل الجد، ستصل عاجلاً أم آجلاً إلى نفس النقطة: أنت بحاجة إلى اختبارات الوحدة التي تمنحك الثقة لتتمكن من التعامل مع الكود دون خوف. وهنا يصبح Jest، إلى جانب أدوات مثل مكتبة اختبار React أو jest-preset-angular، أفضل حلفائك.

سنرى في هذا الدليل، بهدوء ولكن بشكل مباشر، كيف قم بتخطيط وتنفيذ استراتيجية اختبار وحدة الواجهة الأمامية باستخدام Jestما هي أنواع الاختبارات التي من المنطقي تشغيلها، وكيفية إعدادها في مشاريع React أو Angular أو TypeScript، وكيفية كتابة اختبارات جيدة (دون الخوض في تفاصيل التنفيذ)، وما هي الأدوات التي لديك لمقارنة النتائج، والعمل مع DOM، والنماذج الوهمية، والبرمجة غير المتزامنة، والتغطية، وغير ذلك الكثير.

لماذا تُعدّ اختبارات الوحدة مهمة للغاية في تطوير واجهات المستخدم؟

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

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

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

اختبار الكأس وأنواع الاختبارات في الواجهة الأمامية

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

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

الاختبار الثابت: أدوات فحص الأخطاء وتحليل الكود

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

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

في مشاريع TypeScript الحديثة، من الشائع الجمع بين ESLint ومترجم TS الخاص لاكتشاف أخطاء الأسلوب ومشاكل النوع قبل حتى تشغيل الاختبار باستخدام Jest.

اختبارات الوحدة: خط الدفاع الأول

تُجرى اختبارات الوحدة على أصغر وحدة منطقيةيمكن أن تكون وحدة المنطق دالة خالصة، أو أسلوبًا، أو خطافًا، أو مكونًا صغيرًا، أو خدمة بسيطة. في البرمجة الخلفية، نتحدث عادةً عن الأصناف والأساليب؛ أما في البرمجة الأمامية، فقد تكون الوحدة أيضًا مكونًا أو جزءًا من منطق مُغلّف.

في بيئة جافا سكريبت وتايب سكريبت، سترى أسماءً مثل جيست، موكا، شاي أو Vitest، على الرغم من أن Jest أصبح المعيار الفعلي للواجهة الأمامية، ويرجع ذلك أساسًا إلى تكامله مع مكتبة اختبار رد الفعل وتقديمها على النحو التالي jest-preset-angular.

من المهم أن نتذكر أن لا تهتم اختبارات الوحدة بالتنفيذ الداخليلكن فيما يتعلق بالناتج المتوقع: بالنظر إلى مدخلات معروفة، يجب أن تنتج الدالة أو المكون نتيجة معينة، بغض النظر عن كيفية كتابتها داخليًا.

اختبارات التكامل: التأكد من أن الأجزاء تتواصل مع بعضها البعض

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

• وهي تحدد سيناريوهات تتعاون فيها عدة أطراف: نموذج يستدعي خدمة، والتي بدورها تقوم بتحويل البيانات وعرضها في الواجهة.
• تساعد هذه الأدوات في اكتشاف الأخطاء في الحدود بين الوحدات النمطيةوهذا هو المكان الذي غالباً ما تتسلل إليه أخطاء البيانات أو أنواعها أو عقود واجهة برمجة التطبيقات.
• في واجهة المستخدم باستخدام TypeScript، يمكنك الاعتماد على Supertest أو Cypress أو حتى الاختبارات باستخدام Jest التي تختبر العديد من المكونات والخدمات في وقت واحد.

في عالم React، يتم اختبار هذا "التكامل" عادةً باستخدام مكتبة اختبار React + Jestيتم عرض المكونات المستخدمة بالفعل من قبل مكونات داخلية أخرى وخدمات وهمية. في Angular، من الشائع بناء المكون باستخدام TestBed واستخدام Jest كمحرك عرض بدلاً من Karma/Jasmine.

اختبار شامل (E2E): رحلة المستخدم الكاملة

تحاكي اختبارات E2E السلوك الفعلي للمستخدم التنقل في التطبيق: يفتحون الصفحات، وينقرون، ويملؤون النماذج، وينتظرون الردود من جانب الخادم.

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

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

ما هو اختبار الوحدة تحديداً، وما الذي يجعله جيداً؟

وبعيداً عن التصنيفات، يتساءل الكثيرون: ما الذي يُعتبر اختبارًا للوحدات في تطوير واجهات المستخدم؟مكون واحد؟ دالة؟ صفحة كاملة؟

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

السمات الرئيسية لاختبار الوحدة المفيد

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

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

Jest كإطار عمل لاختبار الواجهة الأمامية

لقد استحق جيست مكانته كـ إطار الاختبار السائد في بيئة جافا سكريبتتستخدمه شركات كبيرة مثل فيسبوك، وإير بي إن بي، وتويتر، وسبوتيفاي لاختبار تقنيات الواجهة الأمامية الخاصة بها مثل React وAngular وغيرها.

واحدة من مزاياها العظيمة هي ذلك لا يتطلب الأمر أي إعدادات تقريبًا لبدء التشغيل في مشاريع JavaScript أو TypeScript، ويأتي مزودًا بأدوات مدمجة للمحاكاة والتجسس والتأكيدات وتغطية التعليمات البرمجية، مما يجنب الاعتماد على آلاف المكتبات الإضافية.

الوظائف الأساسية: الوصف، الاختبار، قبل كل فصل، وبعد كل فصل

يعتمد الهيكل النموذجي لملف اختبار Jest على بعض الكتل الرئيسية التي ستراها مرارًا وتكرارًا:

• وصف(الاسم، الدالة)يُصنّف هذا الاختبارات ذات الصلة تحت وصف واحد، مما يُسهّل تنظيم النتائج وقراءتها في وحدة التحكم.
• اختبار(الاسم، الدالة) o it(name, fn)حدد اختبارًا معينًا. كلا الدالتين متكافئتان؛ اختر ما تفضله.
• قبل كل (fn)يُجرى هذا الاختبار قبل كل اختبار جماعي. وهو مثالي لـ تهيئة الحالة الأولية، نماذج محاكاة أو حالات شائعة.
• بعد كل (fn)يتم تنفيذ هذا الأمر بعد كل اختبار. وهو مفيد لعمليات التنظيف، واستعادة النماذج الوهمية، أو إغلاق الاتصالات المحاكاة.

في أي اختبار وحدة، داخل الدالة التي تمررها إلى تجربه بالعربي o itستتبع دائمًا نفس النمط تقريبًا: تقوم بإعداد البيانات، وتنفيذ الدالة أو عرض المكون، ثم تستخدم يتوقع(…) للتأكد من النتيجة المتوقعة.

أدوات المطابقة والمقارنات في Jest

جوهر التأكيدات في Jest هو الوظيفة توقعوهو ما يرتبط بطرق مختلفة لفحص حالات مختلفة. ومن أكثرها شيوعاً ما يلي:

• .toBe(value): يتحقق من المساواة التامة باستخدام Object.isمثالي للأرقام والسلاسل النصية والقيم المنطقية.
• .toEqual(obj): يقوم بإجراء المقارنة المتكررة من الكائنات والمصفوفات، مثالية لهياكل البيانات المعقدة.
• .لا: يعكس عملية المطابقة، على سبيل المثال توقع (خطأ).ليس.أن يكون (صواب).
• .toBeDefined(): يتحقق من أن القيمة ليست undefined.
• .toContain o توقع.مصفوفة تحتوي على: التحقق من أن المصفوفة أو السلسلة النصية تتضمن عناصر معينة.

وانطلاقاً من هذا الأساس، يضيف Jest العديد من الميزات المحددة الأخرى: .toHaveBeenCalled, .toHaveBeenCalledTimes, .toHaveBeenCalledWith للامتحانات التجريبية، .toThrow بالنسبة للأخطاء، أو أدوات المطابقة الموسعة عند دمج مكتبات مثل @ testing-library / jest-dom للعمل مع نموذج كائن المستند (DOM).

اختبار DOM باستخدام مكتبة اختبار React

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

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

أنواع الاستعلامات: getBy و queryBy و findBy

توفر مكتبة اختبار React أنواعًا مختلفة من الدوال للبحث عن العناصر في DOM المُصَوَّر، عادةً من خلال الكائن شاشة:

• تجاوز الأمر…ابحث عن عنصر و يُظهر خطأً إذا لم يتمكن من العثور عليه.هذا ما تريده عندما يكون وجود العنصر شرطاً أساسياً لنجاح الاختبار.
• استعلام بواسطة…: يقوم بنفس البحث ولكن يُرجع قيمة فارغة (null) إذا لم يكن موجودًا، دون الإخلال بالاختبار. مفيد للتحقق من عدم وجود شيء ما.
• findBy…: نفس وظيفة getBy، ولكن موجه نحو العمليات غير المتزامنةيقوم بإرجاع وعد وينتظر ظهور العنصر في DOM بعد طلب HTTP، أو مهلة زمنية، وما إلى ذلك.

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

استعلامات مُوصى بها للعثور على العناصر

تقترح وثائق مكتبة الاختبار الرسمية ترتيبًا للأفضلية للاستعلامات، مع الحرص دائمًا على محاكاة كيفية إدراك المستخدم للواجهة:

1. الحصول على الدور (مع خيار nameهذا هو الاستعلام الأكثر دلالة، حيث يحدد العناصر بناءً على دورها في الوصول (زر، عنوان، مربع نص، إلخ). ينبغي أن يكون خيارك الأول دائمًا تقريبًا.
2. getByLabelText: مثالي ل حقول النموذجيتيح لك هذا البرنامج العثور على المدخلات ومناطق النصوص من خلال التسمية المرتبطة بها، تمامًا كما يفعل قارئ الشاشة.
3. getByPlaceholderText: مفيد عندما يكون هناك عنصر نائب واحد فقط مرئي، على الرغم من أنه لا يحل محل التسمية المناسبة.
4. getBytext: ل المحتوى المرئي في العناصر غير التفاعلية: الفقرات، وعناصر div، وعناصر span، وما إلى ذلك.
5. getByDisplayValue: مفيد جداً للمدخلات المعبأة مسبقاً، حيث يتحقق من القيمة التي يراها المستخدم.

بالإضافة إلى ذلك، لديك ما يسمى "الاستعلامات الدلالية":

1. getByAltText: يحدد موقع الصور أو العناصر الأخرى ذات السمة alt، وهو أمر ضروري لإمكانية الوصول.
2. getByTitleيعتمد ذلك على السمة titleلكن هذا لا تتم قراءته دائمًا بواسطة برامج قراءة الشاشة.

وأخيراً، كحل أخير getByTestId، والتي تبحث عن العناصر التي تحتوي على سمة data-testid. يُفضل استخدامه في الحالات التي لا توجد فيها طريقة معقولة أخرى لتحديد موقع العنصر (نص ديناميكي، عناصر زخرفية بحتة، إلخ).

الاختبار المتزامن مقابل الاختبار غير المتزامن في Jest

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

من الواضح أن الاختبار متزامن في الحالات التالية:

• لا يستخدم وظائف غير متزامنة ni await.
• لا يقوم باستدعاء واجهات برمجة التطبيقات غير المتزامنة ولا للخدمات التي تفي بوعودها.
• لا يعتمد ذلك على setTimeout، setInterval أو ما شابه ذلك.

بل هو اختبار غير متزامن في الحالات التالية:

• تم تمييز دالة الاختبار بـ async وتوظيف await.
• يعمل مع الدوال التي تُرجع وعودًا (fetch، و axios، وخدمات HTTP، وما إلى ذلك).
• في مكتبة اختبار React، استخدم طرق البحث عن طريق أو الانتظار انتظار حدوث تغييرات في DOM.

يكمن المفتاح في التأكد من أن Jest انتظر بصبر حتى تنتهي تلك العمليات.للقيام بذلك، يمكنك إرجاع وعد من الاختبار، أو استخدام async/await، أو في واجهات برمجة التطبيقات القديمة، استخدام رد نداء. done يقوم Jest بحقنها في دالة الاختبار.

إنشاء اختبارات الوحدة باستخدام Jest في مكونات واجهة المستخدم

لتوضيح كيفية اختبار المكونات الحقيقية، تخيل أن لديك زرًا وبعض المكونات الأكثر تعقيدًا في React. تتمثل الممارسة المعتادة في إنشاء ملفات مثل Button.test.tsx o HomeComponent.spec.ts واستخدم Jest مع مكتبة الاختبار المناسبة.

الحالة الأولى النموذجية هي تأكد من عرض المكون بالنص الصحيحتقوم بعرض الزر باستخدام مكتبة اختبار React، وتبحث عن النص "انقر هنا" أو ما شابه، وتتحقق من وجود هذا العنصر في المستند باستخدام أداة مطابقة مثل toBeInTheDocument.

ومن الأنماط الأخرى التي تتكرر كثيراً استخدام jest.fn() لإنشاء دوال وهمية تعمل كمعالجات للأحداث أو دوال رد نداء. بهذه الطريقة، يمكنك التحقق مما إذا تم استدعاؤها عندما ينقر المستخدم، أو يغير قيمة مُدخلة، أو يُفعّل إجراءً مُحددًا.

في المكونات الأكثر تعقيدًا، مثل النماذج أو النوافذ المنبثقة، من الشائع جدًا إعداد كائن معالج يحتوي على العديد من الوظائف الوهمية باستخدام jest.fn()مررها كخاصية ثم استخدمها expect(handlers.something).toHaveBeenCalled() لضمان تشغيل منطق الحدث في الوقت المناسب.

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

تكوين Jest الأساسي في مشاريع React باستخدام TypeScript

لاستخدام Jest في تطبيق React مع TypeScript، تبدأ عملية العمل عادةً بالتأكد من أن لديك Node.js و npm (أو yarn) مثبتة ومشروع React أساسي (على سبيل المثال، تم إنشاؤه باستخدام Create React App أو Vite، وتم تكييفه مع TS).

في المشاريع القائمة، تتمثل الممارسة المعتادة في تثبيت برامج التطوير التالية: jest، و@testing-library/react، و@testing-library/jest-dom، وأنواع Jest لـ TypeScriptبعد التثبيت، يمكنك إنشاء ملف تكوين مثل jest.config.js o jest.config.cjs حيث تقوم بتحديد البيئة، ومحول TypeScript، والمسارات ذات الصلة.

في package.json تُضاف هذه النصوص البرمجية عادةً على الأقل: "اختبار": "مراقبة - نكتة" لتشغيل الاختبارات في وضع المراقبة أثناء التطوير، و «test:coverage»: «jest –coverage» لإنشاء تقارير التغطية ومعرفة أجزاء الكود التي لا يتم اختبارها، ولدمجها في مسارات التكامل المستمر/التسليم المستمر (CI/CD)، يمكنك اتباع دليل لـ قم بتهيئة تدفق التكامل المستمر/التسليم المستمر باستخدام GitHub Actions.

يمكن تهيئة Jest افتراضيًا للبحث عن الملفات التي ينتهي اسمها بـ .test.tsx أو .spec.tsx (في حالة React مع TypeScript)، مما يبسط التنظيم بشكل كبير: يمكنك وضع الاختبارات بجوار المكونات أو في مجلد اختبارات محدد، ويتولى Jest مهمة تحديد موقعها.

دمج Jest يدويًا في مشاريع Angular

في Angular، تاريخياً، تم إعداد الاختبارات باستخدام ياسمين وكارمايعتبر الكثيرون هذا الأمر بطيئًا وغير سهل الاستخدام لعمليات التكامل المستمر/التسليم المستمر. تم تقديم خيارات تجريبية لاستخدام Jest في Angular 16، ولكن إذا كنت ترغب في شيء مستقر، يبقى المسار اليدوي هو الأكثر موثوقية.

في مشروع Angular حديث (على سبيل المثال، تم إنشاؤه باستخدام Angular CLI 17)، فإن العملية النموذجية للتحويل إلى Jest تتبع عادةً الخطوات التالية:

• أنشئ المشروع مع ng new project-test-jest والتكوين الذي تحتاجه.
• قم بإلغاء تثبيت Karma و Jasmine باستخدام npm، إزالة الحزم مثل karma, jasmine-core والإدارات الأخرى ذات الصلة.
• قم بإزالة هذا من ملف angular.json قسم إعدادات الاختبار القائم على Karma، لأنك لن تستخدمه.
• قم بتثبيت Jest و jest-preset-angular مع npm install jest jest-preset-angular @types/jest --save-dev.
• قم بتحديث البرامج النصية في ملف package.json بحيث يقوم الأمر "test" بتشغيل Jest بدلاً من ng testوأضف برنامجًا نصيًا "للتغطية" يقوم بتشغيل jest --coverage.
• قم بتعديل ملف tsconfig.spec.json بحيث تتغير الأنواع من الياسمين إلى المزاح، مما يشير إلى "types":

ثم تحتاج إلى إنشاء ملف jest.config.js في صميم المشروع، ويعتمد عادةً على jest-preset-angularهناك يمكنك تحديد أشياء مثل جذر الاختبار، ومسار ملف الإعداد، وأسماء الوحدات النمطية (moduleNameMapper)، والملفات التي يتم احتسابها ضمن التغطية.

وأخيرًا، تضيف src/setup-jest.ts هذا مهم "الدعابة الزاويّة المُعدّة مسبقًا/الإعداد الدعابة"هذا يهيئ بيئة Angular للتشغيل بشكل صحيح في Jest، بما في ذلك JSDOM والميزات الأخرى.

أمثلة على الاختبار في Angular باستخدام Jest: المكونات والخدمات

في Angular، تعتمد اختبارات المكونات عادةً على سرير اختبار لتثبيت المكون داخل وحدة اختبار، وحقن الخدمات، وإدارة دورة اكتشاف التغييرات.

على سبيل المثال، تخيل الصفحة الرئيسية للمكون والتي لها خصائص مثل title, count, isVisible y dataوذلك في ngOnInit يطلب البيانات من خدمة العينة. و قبل كل عادةً، أقوم بتكوين TestBed باستخدام الوحدة النمطية أو عمليات الاستيراد اللازمة، وتسجيل الخدمة، وإنشاء مكون التركيب.

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

ثم يمكنك اختبار تفاعل المستخدم مع أزرار تزيد عدادًا أو تُبدّل قيمة رؤية منطقية. مع fixture.debugElement.query(By.css('.class')) تجد الأزرار، وتقوم بتشغيل الأحداث باستخدام triggerEventHandler('click', null) وتتحقق من أن خصائص المكون تتغير كما هو متوقع بعد استدعاء fixture.detectChanges().

بالنسبة لخدمات Angular التي تستدعي واجهات برمجة التطبيقات الحقيقية، فإن الزوج HttpClientTestingModule و HttpTestingController إنه أمر ضروري. يتم تكوينه في beforeEach، ويتم حقن الخدمة ووحدة التحكم، وبعد كل اختبار، يتم استدعاؤه. httpMock.verify() لضمان عدم بقاء أي طلبات معلقة.

قد يشترك اختبار خدمة HTTP النموذجي في service.getPokemon('pikachu')، تحقق من ذلك HttpTestingController استقبل طلب GET إلى عنوان URL الصحيح وقم بالرد بـ req.flush(mockPokemon)في التأكيدات، تم التحقق من أن البيانات التي تم إرجاعها إلى المشترك تتوافق مع النموذج الوهمي.

اختبار اللقطات والمحولات المخصصة

يُتيح لك Jest أيضًا القيام بما يلي اختبار اللقطةهذا شائع جدًا في مكونات React. الفكرة بسيطة: تقوم بعرض المكون (على سبيل المثال باستخدام react-test-renderer)، تقوم بحفظ مخرجاته في ملف لقطة، وفي عمليات التشغيل اللاحقة، تقارن ما يتم عرضه مع ذلك الملف.

عندما يتم تغيير المكون عمدًا، يمكنك قم بتحديث اللقطة مع أمر مثل jest -uإذا كان الاختلاف غير متوقع، فسيفشل الاختبار ويجبرك على التحقق بالضبط مما تغير في المخرجات المعروضة.

مع React 16+ ومكتبات مثل Enzyme، قد يكون هناك تحذيرات وحدة التحكم عند محاكاة مكونات معينةيعود ذلك إلى طريقة تحقق React من أنواع العناصر. تتضمن بعض الاختصارات عرضها كنص عادي، واستخدام عناصر مخصصة (مثل التسميات التي تحتوي على شرطات وأحرف صغيرة)، والاعتماد على... مُعرِّض اختبار React أو، في الحالات القصوى، قم بتعطيل بعض التحذيرات في إعدادات Jest.

إذا كان مشروعك يتطلب تحويلًا أكثر تقدمًا للبرمجيات، يمكنك أيضًا تعريف المحولات المخصصة في Jest. بدلاً من مجرد استخدام babel-jest، يمكنك اللجوء إلى @ بابل / كور y babel-preset-jestتكوين مفتاح "transform" الخاص بـ Jest لمعالجة الملفات باستخدام قواعدك الخاصة.

أفضل الممارسات عند كتابة اختبارات الوحدة باستخدام Jest

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

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

بمجرد تشغيل Jest باستخدام Cover (على سبيل المثال، باستخدام تغطية تشغيل npmستحصل على دليل تغطية مع تقرير HTML مرئي للغاية يُظهر الملفات والأسطر التي تم تنفيذها في الاختبارات. فتح coverage/lcov-report/index.html يمكنك التنقل بين الملفات واحداً تلو الآخر، وهو أمر مثالي للكشف عن... المناطق المظلمة في تطبيقك ينبغي تغطية ذلك.

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