عادةً ما يتم تجاوز مواصفات الكتابة - التأكيدات أو فرضيات الاختبار - في دورات TDD نظرًا لوجود القليل من البرمجة.
ومع ذلك ، فهي مهمة جدا.
إنهم يحددون كيفية وما هي الاختبارات التي سيتم كتابتها ، ويحددون أيضًا مدى سهولة إصلاح الخلل. انهم تقريبا لا تتطلب وقتا للتنفيذ. هم أول من يربط مستخدم القصة والرمز والأول الذي يظهر فشل كود الاختبار. هم أيضًا ما يحميننا بالإضافة إلى ذلك من الأخطاء في رمز الاختبار نفسه.
كيف يمكننا أن نجعل بياناتنا أفضل؟
أولاً ،
يجب أن تكون المواصفات مرتبطة بقصة المستخدم من حيث المصطلحات . إذا كان مستخدم القصة يستخدم مصطلح "تسجيل الدخول" ، فلا يمكن التأكيد على تغيير هذا المصطلح للمصادقة / الترخيص / التحقق من الصحة. إذا لم تتم كتابة القصة جيدًا ، فقم بتغييرها.
ثانياً ،
يجب أن تحتوي المواصفات صراحةً على اسم المكون الذي تصفه. يشير هذا إلى منطقة الاختبار ويشير إلى وجود خطأ ، إذا كان الأوسبري فجأة يشتمل على بعض المكونات غير المتوقعة.
يتم دمج البرنامج النصي الصحيح مع مبدأ المسؤولية الفردية ، لذلك يجب أن يتطابق اسم المكون مع وصف الاختبار. إذا كان هناك العديد من السيناريوهات الصالحة ، فمن المحتمل أن يتحمل المكون الكثير من المسؤولية.
أيضًا ، يصف سيناريو واحد ، كحدث ، واجهة مستخدم أو نوع من النمط. قد يحتوي المرشحون الجيدون على اسم المكون على اسم النموذج: المدقق ، والاستراتيجية ، والباني ، والمحول ، والمراقب ، إلخ. أو اسم الحدث: مقدم ، تسجيل الدخول ، ReadonlyOrderView ، الخ أي اعتمادًا على اسم المكون ، يجب تحديد قيم المدخلات والمخرجات الخاصة بالوظيفة الرئيسية للفئة. أسماء سيئة: مجردة للغاية (الخدمة ، المكون ، المساعد ، المنفعة) ومزدوجة (ValidatorAndRenderer).
ثالثًا ،
يجب أن توضح المواصفات الشروط صراحة .
الفقراء:
@Test public void testValidatePassword(){}
أفضل:
@Test public void loginController_whenValidUsername_andValidPassword_shouldLogUserIn(){}
ليس من الضروري استدعاء هذه الوظيفة من مكان آخر ، لذلك تكون الأسماء الطويلة جدًا صالحة. إذا كان عدد الشروط في الاختبار غير مناسب على الخط ، فربما يجب عليك تغيير بنية المكون.
بالنسبة إلى javascript ، يقوم باختبار نفس الشيء ، ولكن يمكنك وضع الشروط هناك ، فإنه يصبح أكثر ملاءمة.
describe('login UI component', () => { describe('when username provided', () => { describe('when valid password', () => { it('should log user in', () => { ... }); }); }); });
الظروف الصريحة أسهل في القراءة
والعثور عليها مفقودة .
بالإضافة إلى ذلك ، إذا كانت الحالة لا تتطابق مع رمز الاختبار المكتوب ، فمن السهل تصحيح الرمز.
وصف جيد ، بشكل عام ، هو بديل للتوثيق وتعليق الكود. إنه مجرد ملخص ، ولا يعتمد على الإطار والمترجم ، ويجب أن يعامل بنفس الجدية مثل الأخيرين.
يجب أن تكون الشروط نفسها متسقة في التعليمات البرمجية لسهولة القراءة ، على سبيل المثال GIVEN-WHEN-THEN-SHOULD ، إلخ.
رابعا ،
يجب تبسيط المواصفات . من المفيد كتابتها بترتيب عكسي:
الأخطاء أولا ، لاغية أولا ، مسار سعيد الماضي. ثم ليست هناك رغبة لإنهاء الاختبار بعد حالة مستخدم واحدة صالحة. لمكونات واجهة المستخدم: التقديم ، والأحداث. بالنسبة للمكونات ذات الحالة ، تكون جميع الحالات متسقة.
وهكذا ، تبدو بنية مواصفات جيدة قابلة للقراءة: 5-10 ، برنامج نصي خاطئ واحد (أو عدة أشكال من برنامج نصي واحد)
من الممارسات الجيدة عند كتابة أحد المواصفات أن تكتبه بالكامل في شكل نص ، ثم تعطيه إلى زميل ليتم قراءته من أجل الوضوح والظروف المفقودة. ثم ، في الواقع ، يمكنك بالفعل البدء في كتابة التطبيق. في كثير من الأحيان ، في هذا النموذج ، تنفر المهمة ، أي حسنا ، عندما يكتب شخص آخر تنفيذ الاختبار.
خامسا ،
يجب أن يتوافق تنفيذ الاختبار مع ما هو مكتوب في الوصف .
من الممارسات الجيدة أن تقسم إلى ترتيب - فعل - تأكيد للعثور بسهولة على جزء أو جزء آخر من التطبيق. يجب أيضًا ربط نص التأكيدات والاستثناءات ، إذا كان موجودًا ، بأوصاف الاختبار ، كقاعدة عامة ، يمكننا ببساطة تكرارها.
لا حاجة للقول ، عند إضافة شروط أو تأكيدات للاختبار ، تحتاج أيضًا إلى تحديث أوصاف الاختبار.
لذلك ، قد يكون تسلسل كتابة المواصفات كما يلي.
- قراءة قصة المستخدم
- اسم المكون والبرنامج النصي صالح
- صياغة الشروط لسيناريو صالح
- تكملة المواصفات مع البرامج النصية الخاطئة عن طريق وضعها على القمة
- دع الجار يقرأ ويصحح المفقود
- تنفيذ الاختبارات والمكونات واحدا تلو الآخر باستخدام حلقة الأحمر والأخضر ريفاكتور.