نود أن نلفت انتباهك إلى حداثة أخرى متوفرة في طلبنا المسبق - كتاب عن اختبار الوحدة .
يتحدث مؤلف منشور اليوم باختصار وبسهولة عن مزايا اختبار الوحدة و TDD باستخدام الواجهة الأمامية كمثال.
استمتع بالقراءة!
يعد اختبار الوحدة أحد أهم الأساليب التي يجب على كل مطور اتباعها. ومع ذلك ، فقد رأيت العديد من المشاريع حيث قد يكون من الصعب وضع اختبار الوحدة موضع التنفيذ. هناك عديد من الأسباب لذلك. على سبيل المثال ، قد يقول شخص ما أنك بحاجة إلى التركيز على تطوير الميزات ، وكتابة اختبارات الوحدة في هذه الحالة يمثل عبئًا إضافيًا خطيرًا. سيلاحظ الآخرون أن اختبار الكود الخاص بهم ليس بالأمر الهين لأن الكود نفسه معقد. في كلتا الحالتين ، يتم تفويت النقطة.
أتذكر هذا التعبير: عند التفكير فيما إذا كان لديك وقت لكتابة اختبارات الوحدة ، فكر فيما إذا كان لديك وقت إضافي لمعالجة نفس الكود مرتين ، بسبب الأخطاء والمشكلات التي ستظهر فيه.
كتابة كود قابل للاختبار
أولاً ، دعنا نحدد الأخطاء الشائعة التي تجعل اختبار الكود أكثر صعوبة. عندما يتعلق الأمر باختبار الواجهة الأمامية ، فإن إحدى أصعب المشكلات التي أعرفها هي اختبار مكونات واجهة المستخدم. المشكلة الرئيسية التي واجهتها في هذه الحالة هي: يحدث أن المكونات "ذكية" للغاية ومعلقة مع التبعيات على أجزاء الكود الأخرى ، على سبيل المثال ، من مكالمات API ، وتحميل البيانات ، ومعالجة الأحداث ، وتنفيذ منطق الأعمال. لا يحب العديد من المطورين كتابة الاختبارات لمثل هذه المكونات "الثقيلة".
إن أبسط حل لهذه المشكلة هو فصل المكونات إلى منطق وعرض. باستخدام هذا الفصل ، يمكنك اختبار كيفية التزام مكونات العرض التقديمي بمنطق العرض التقديمي ، وتنفيذ معالجة الأحداث وتقديمها ، والتركيز بشكل منفصل على اختبار منطق الأعمال في المكونات المسؤولة عن المنطق.
يعد التأكد من أن مكوناتك قابلة للاختبار أيضًا طريقة جيدة للتأكد من أنها مستقلة وقابلة لإعادة الاستخدام وملائمة للاستخدام معًا. هذا ضروري للغاية ، لا سيما عند مشاركة المكونات عبر المشاريع باستخدام الأدوات والأنظمة الأساسية الشائعة مثل Bit ( Github). عادةً ، سيعرض Bit ويختبر كل مكون من مكوناتك على حدة ، وبعد ذلك فقط يرسلهم إلى مجموعة مشتركة ، وبالتالي يضمن أنها قابلة لإعادة الاستخدام بالفعل - وإلا ، ما الهدف من جعلها قابلة للفصل.
مثال: استكشاف مكونات React القابلة لإعادة الاستخدام المشتركة على Bit.dev
حلقة مفرغة: ماذا يحدث إذا لم تكتب اختبارات الوحدة
من واقع خبرتي مع الفرق التي لا تطبق اختبار الوحدة بشكل صحيح (أي ، لا تستخدم تغطية الاختبار كمقياس) إما بدأت في اختبار الوحدة بعد فوات الأوان ، أو من البداية ، لكن لم تتعلم كيفية ممارستها. قد يكون هناك العديد من الأسباب لذلك ، لكنني سأقدم بعض الأمثلة لتسهيل تحديد أيهما أكثر تشابهًا مع حالتك.
كيف نختبر الكود الخاص بنا أثناء التطوير
في رأيي ، ما لم تلتزم بالتطوير القائم على الاختبار (TDD) ، فيمكن عندئذٍ تطوير الوظائف بشرط أن يتم تحميل الواجهة الأمامية باستمرار في المتصفح. تحتاج إلى التركيز على تصور الوظائف والتفاعلات التي تحدث في واجهة المستخدم ، لأن هذا هو جوهر التطوير من جانب العميل.
بعد ذلك فقط ، عندما تعمل جميع الوظائف بالفعل ، ينتقل التركيز إلى اختبار الوحدة.
ها هي المشكلة الرئيسية التي يجب عليك مواجهتها: اختبارات وحدة الكتابة هي جزء إضافي من العمل يتم تنفيذه بعد اكتمال تطوير الوظيفة. يؤدي هذا النهج إلى الانطباع بأن اختبار الوحدة هو مهمة إضافية يتم إجراؤها بالإضافة إلى تطوير الوظائف الجاهزة.
بسبب صياغة السؤال هذه ، يصنف مالكو المنتج والمطورون اختبار الوحدة على أنه تكلفة.
ولكن إذا التزمت بـ TDD ، فإن كل شيء يتطور عكس ذلك تمامًا. نظرًا لأن حالات الاختبار مكتوبة مسبقًا ، فلا يتعين علينا التحقق من كل شيء من خلال تصور التغييرات باستمرار ، لأن لدينا طريقة مختلفة للتحقق من الكود أثناء التطوير. في هذه الحالة ، تتمثل أداة التحقق الرئيسية في كتابة رمز يجتاز حالة اختبار الوحدة.
لذلك ، أعتقد أن ممارسة TDD هي أهم مرحلة قبل ممارسة اختبارات الوحدة.
كم مرة يتم إجراء اختبارات الوحدة
قد تتساءل عن كيفية تأثير إجراء اختبار الوحدة على كيفية كتابة اختبارات الوحدة. على سبيل المثال ، لنفترض أن لديك مجموعة كاملة من الاختبارات. أنت تطرده من وقت لآخر. لذلك ، نادرًا ما يقتنع المطورون بفائدته. علاوة على ذلك ، حتى في الحالات التي ثبت فيها فشل الاختبار ، فقد فات الأوان.
لذلك ، من المهم تشغيل اختبارات الوحدة على الأقل في كل مرحلة من مراحل بناء طلب السحب. من خلال الالتزام بهذه الممارسة ، المأخوذة من DevOps ، نضمن أن كل كتلة جديدة من التعليمات البرمجية نضيفها تمر بمجموعة من اختبارات الوحدة. حتى إذا كانت هناك حاجة لتغيير حالة معينة ، فسيقوم المطور بذلك قبل إجراء دمج الكود.
كم مرة لقياس تغطية الكود عن طريق الاختبارات
كما هو الحال مع تنفيذ الاختبار ، يعد هذا القياس مهمًا أيضًا من الناحية النفسية وكممارسة للمطورين للحكم على ما إذا كانوا يعدون حالات اختبار كافية لتغطية جميع التعليمات البرمجية المكتوبة.
في هذه الحالة ، أعتقد أن لوحة القيادة وحدها لا تكفي ، حيث يمكنك عرض تغطية اختبارات الوحدة. ولكن ، إذا كان من الممكن إضافة إجراء قياس عند إضافة رمز جديد وبالتالي التحقق من مستوى تغطية الاختبار ، فسيكون هذا البديل أكثر ملاءمة للحصول على ردود فعل فورية. يمكننا حتى صياغة قواعد تتطلب أن أي كود جديد يضاف إلى قاعدة البيانات يجب أن يتم تغطيته بالاختبارات ، على سبيل المثال ، 80٪. من الأنسب إضافة هذا التحقق إلى عملية إنشاء طلب السحب.
نظرًا لأن المطورين يتلقون تعليقات فورية حول تغطية اختبار الوحدة لشفراتهم ، فإنهم أحرار في اتخاذ خطوات للحاق بهذه التغطية حسب الحاجة.
الخروج من هذه الدائرة
إذا كنت منخرطًا بالفعل في هذه الحلقة المفرغة ، فإن أفضل طريقة للخروج منها هي تعزيز الممارسات التي نوقشت أعلاه. نظرًا لأن ما ورد أعلاه كان متعلقًا باختبار متكرر للتحقق من صحة التعليمات البرمجية المضافة حديثًا ، بالإضافة إلى اختبار تغطية الكود الجديد ، يمكنك تطوير إجراء مناسب لأي عملية إضافة أو تغيير رمز.
من غير المرجح أن يكون لديك الوقت الكافي لتغطية جميع الكود القديم بالاختبارات (ما لم يكن المشروع نفسه جديدًا تمامًا) على الفور ، قبل أن تضطر إلى كتابة رمز جديد. لذلك ، لا تعتمد عليه على الإطلاق ، لأنه من وجهة نظر العمل ، فهو غير عملي.في غضون ذلك ، يمكنك إجراء قياسات دورية تغطي بشكل استراتيجي أجزاء معينة من الكود القديم من خلال الاختبارات. والأهم من ذلك ، يجب تدريب جميع المطورين على اتباع هذه الممارسة. من المهم بنفس القدر عدم اعتياد نفسك على اعتبار هذا العمل تكلفة وإبلاغ جميع أصحاب المشروع بمدى أهمية كتابة اختبارات الوحدة. خلاف ذلك ، قد يعتقد الكثير من الناس ، وخاصة غير التقنيين ، أن اختبار الوحدة هو عمل غير ضروري ، وبدلاً من ذلك يمكن للمرء قضاء الوقت في تطوير وظائف جديدة.
إذن ما هي القيمة الحقيقية لكل هذا العمل
اختبارات الوحدة مفيدة في نواح كثيرة. إذا تم تطبيقها بشكل صحيح ، فإنها تساعد في تقليل عدد العيوب في الكود ، وتعمل كضمان عند اختبار الوظائف الحالية ، ولا تتلف عند إعادة بناء الكود ، وتساعد أيضًا في الحفاظ على الإنتاجية الإجمالية عند مستوى عالٍ.
من خلال النظر إلى الكود الذي تمت تغطيته جيدًا من خلال اختبارات الوحدة ، يمكن للجميع رؤية مدى الثقة التي تبدو عليها.لذلك دعونا نملأ الفجوات ونعود إلى المسار الصحيح من خلال اعتماد ممارسات DevOps والتعود على كتابة اختبارات وحدة جيدة مع التمسك أيضًا بالتطوير القائم على الاختبار.