TDD: विनिर्देशों को सही तरीके से कैसे लिखें (वर्णन)

लेखन विनिर्देशों - अभिकथन या परीक्षण परिकल्पना - आमतौर पर टीडीडी पाठ्यक्रमों में बाईपास किया जाता है क्योंकि बहुत कम प्रोग्रामिंग है।

हालांकि, वे बहुत महत्वपूर्ण हैं।

वे निर्धारित करते हैं कि परीक्षण कैसे और क्या लिखा जाएगा, और यह भी निर्धारित करें कि ब्रेकडाउन को ठीक करना कितना आसान होगा। उन्हें लगभग कार्यान्वयन के लिए समय की आवश्यकता नहीं है। वे पहले हैं जो कहानी के उपयोगकर्ता और कोड को जोड़ते हैं और पहला जो परीक्षण कोड की विफलता को दर्शाता है। वे भी हैं जो अतिरिक्त रूप से हमें परीक्षण के कोड में त्रुटियों से बचाता है।

हम अपने बयानों को बेहतर कैसे बना सकते हैं?

सबसे पहले, विनिर्देशों को उपयोगकर्ता की कहानी से संबंधित होना चाहिए । यदि कहानी का उपयोगकर्ता "लॉग इन" शब्द का उपयोग करता है, तो मुखर इस शब्द को प्रमाणित / अधिकृत / सत्यापित करने के लिए नहीं बदल सकता है। अगर कहानी अच्छी तरह से नहीं लिखी गई है, तो इसे बदल दें।

दूसरे, विनिर्देश में स्पष्ट रूप से उस घटक का नाम होना चाहिए जिसका वे वर्णन करते हैं। यह परीक्षण क्षेत्र को दर्शाता है और एक त्रुटि को इंगित करता है, अगर अचानक ओस्प्रे में अक्सर कुछ अप्रत्याशित घटक शामिल होते हैं।

मान्य स्क्रिप्ट एकल जिम्मेदारी सिद्धांत के साथ अच्छी तरह से जोड़ती है, इसलिए घटक का नाम परीक्षण विवरण के अनुरूप होना चाहिए। यदि कई वैध परिदृश्य हैं, तो संभवतः घटक की बहुत अधिक जिम्मेदारी है।

इसके अलावा, एक नियम के रूप में, एक परिदृश्य, एक ui-घटना या किसी प्रकार के पैटर्न का वर्णन करता है। घटक नाम के अच्छे उम्मीदवारों में पैटर्न का नाम शामिल हो सकता है: सत्यापनकर्ता, रणनीति, बिल्डर, ट्रांसफार्मर, नियंत्रक इत्यादि। या ईवेंट का नाम: Submitter, Login, ReadonlyOrderView, आदि। यानी घटक के नाम के आधार पर, वर्ग के मुख्य कार्य के इनपुट और आउटपुट मान दोनों को परिभाषित किया जाना चाहिए। बुरे नाम: बहुत सार (सेवा, घटक, सहायक, उपयोगिता) और डबल (ValidatorAndRenderer)।

तीसरा, विनिर्देशों को स्पष्ट रूप से राज्य की स्थिति होना चाहिए ।

खराब:

@Test public void testValidatePassword(){} 

बेहतर:

 @Test public void loginController_whenValidUsername_andValidPassword_shouldLogUserIn(){} 

हमें इस फ़ंक्शन को किसी अन्य स्थान से कॉल करने की आवश्यकता नहीं है, इसलिए अतिरिक्त-लंबे नाम मान्य हैं। यदि परीक्षण में स्थितियों की संख्या लाइन पर फिट नहीं होती है, तो शायद आपको घटक की संरचना को बदलना चाहिए।

जावास्क्रिप्ट के लिए एक ही चीज का परीक्षण करता है, लेकिन आप वहां शर्तें रख सकते हैं, यह अधिक सुविधाजनक है।

 describe('login UI component', () => { describe('when username provided', () => { describe('when valid password', () => { it('should log user in', () => { ... }); }); }); }); 

स्पष्ट स्थितियां पढ़ने और गुम होने को आसान बनाती हैं।

इसके अलावा, यदि स्थिति लिखित परीक्षा कोड से मेल नहीं खाती है, तो कोड को सही करना आसान है।

एक अच्छा वर्णन, सामान्य रूप से, प्रलेखन और कोड टिप्पणी के लिए एक प्रतिस्थापन है। यह सार है, यह रूपरेखा और संकलक पर निर्भर नहीं करता है, और इसे अंतिम दो के समान गंभीरता के साथ व्यवहार किया जाना चाहिए।

आसान पढ़ने के लिए कोड में स्वयं स्थितियां होनी चाहिए, उदाहरण के लिए GIVEN-WHEN-THEN-SHOULD, आदि।

चौथा, विनिर्देशों को सुव्यवस्थित किया जाना चाहिए । उन्हें उल्टे क्रम में लिखना उपयोगी है:

त्रुटियां पहले, अशक्त पहले, सुखी मार्ग अंतिम। फिर एक वैध उपयोगकर्ता मामले के बाद परीक्षण समाप्त करने की कोई इच्छा नहीं है। UI घटकों के लिए: रेंडरिंग, ईवेंट। राज्य घटकों के लिए, सभी राज्य सुसंगत हैं।

इस प्रकार, एक अच्छे पठनीय विनिर्देश की संरचना इस तरह दिखती है: 5-10 गलत, एक मान्य स्क्रिप्ट (या एक स्क्रिप्ट के कई रूप)



पाठ के रूप में इसे पूर्ण रूप से लिखने के लिए विनिर्देशन लिखते समय यह अच्छा अभ्यास है, और फिर इसे स्पष्टता और लापता स्थितियों के लिए पढ़ने के लिए किसी सहकर्मी को दें। फिर, वास्तव में, आप पहले से ही कार्यान्वयन लिखना शुरू कर सकते हैं। अक्सर, इस रूप में, कार्य को अलग कर दिया जाता है, अर्थात। ठीक है, जब कोई और परीक्षण कार्यान्वयन लिखता है।

पांचवां, परीक्षण के कार्यान्वयन के वर्णन के अनुरूप होना चाहिए ।
कार्यान्वयन के एक या दूसरे भाग के लिए आसानी से एक मैच खोजने के लिए व्यवस्था-अधिनियम-मुखर में विभाजित करना अच्छा अभ्यास है। अभिकथन और अपवादों का पाठ, यदि मौजूद है, तो परीक्षण विवरण के साथ भी सहसंबद्ध होना चाहिए, एक नियम के रूप में, हम उन्हें डुप्लिकेट कर सकते हैं।

कहने की जरूरत नहीं है, जब परीक्षण में शर्तों या जोर जोड़ते हैं, तो आपको परीक्षण विवरण को अपडेट करने की भी आवश्यकता है।

इसलिए, विनिर्देश लिखने का क्रम निम्नानुसार हो सकता है।

• उपयोगकर्ता कहानी पढ़ें
• नाम घटक और मान्य स्क्रिप्ट
• मान्य परिदृश्य के लिए स्थितियां बनाएं
• शीर्ष पर रखकर गलत स्क्रिप्ट के साथ विनिर्देश को पूरक करें
• पड़ोसी को पढ़ने और लापता को सही करने दें
• लाल-हरे-परावर्तक लूप का उपयोग करके परीक्षणों और घटकों को एक-एक करके लागू करें।