जेएस और व्यवहार पैटर्न में पठनीय परीक्षण नामकरण

एक मोटे पुल अनुरोध की अगली समीक्षा के दौरान, मैं परीक्षण मामलों के गलत नामकरण के साथ यूनिट टेस्ट में आया। परीक्षण के मामलों में शब्दांकन की चर्चा फिल्म "72 मीटर" ("अगर यह स्कूल में बहुत समझदार थी ...") में यानिचर और लेगोस्तूपोव के बीच की बातचीत के समान थी। वार्तालाप ने यह विचार उत्पन्न किया कि रूसी भाषा के संसाधनों में पाठात्मक शब्दों द्वारा एक व्याख्यात्मक गाइड को ठीक से खोजना मुश्किल है। मैंने खुद को रूसी में खोजने का फैसला किया (आमतौर पर मैं केवल अंग्रेजी बोलने वाले स्रोतों का उपयोग करता हूं)। एक इकाई में यूनिट परीक्षणों के बारे में कई मैनुअल मिले, लेकिन उन सभी ने परीक्षण मामलों में योगों के विवरणों को दरकिनार कर दिया। कटौती के तहत, इस अंतर को भरने का मेरा प्रयास।

Disklemer

एक मौका है कि मैं बुरी तरह से / बुरी तरह से पढ़ रहा था। यहाँ इस बात का एक उदाहरण है कि इस लेख का विषय उन लेखों में कैसे शामिल है जिन्होंने मेरी नज़र को पकड़ा।

शुरुआती के लिए टीडीडी

सहकर्मियों के अनुरोध पर, जो अंग्रेजी मैनुअल पढ़ने में सहज नहीं हैं, मैंने अंग्रेजी भाषा के मैनुअल का अनुवाद और संकलन करने का फैसला किया।

अनुवादक से

मैंने इन दोनों सामग्रियों को लेख के आधार के रूप में लिया:

• महान जावास्क्रिप्ट यूनिट टेस्ट लिखने के लिए 5 टिप्स
• जावास्क्रिप्ट में इकाई परीक्षण के लिए एक गाइड

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

मेरी व्यक्तिगत प्राथमिकता यह है कि कोड में सब कुछ अंग्रेजी में होना चाहिए।

नामकरण परीक्षण

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

BAD उदाहरण:

describe('discoveryService => initDiscoveries', () => { it(' discoveries ( ,    ..)', () => { // ... }); }); describe('MyGallery', () => { it('init      ( , - )', () => { }); // ... }); 

उपरोक्त उदाहरणों से, यह समझना मुश्किल है कि कौन सी विशिष्ट क्रिया (प्रदर्शन) की जा रही है और किस ठोस परिणाम के कारण कार्रवाई होनी चाहिए।

अच्छा उदाहरण:

 describe('discoveryService => initDiscoveries', () => { it('   discoveries', () => { // ... }); it('     discoveries', () => { // ... }); }); describe(' Gallery', () => { it('       ', () => { }); it('       ', () => { }); // ... }); 

लगभग। ट्रांस। # 1: ध्यान दें कि इसमें पाठ का ब्लॉक एक बड़े अक्षर से शुरू होता है, जैसा कि उस वाकये का सिलसिला है जो बेवजह शुरू हुआ।

लगभग। ट्रांस। # 2: ऊपर के उदाहरणों में, "डिस्कवरीसेवी => initDiscoveries" फिर भी दो डेसिब्बे ब्लॉक (एक दूसरे में नेस्टेड है) में अधिक सही ढंग से विभाजित है।

लगभग। ट्रांस। # 3: ध्यान दें कि ऊपर की खोज के बारे में उदाहरण में परीक्षण मामले के विवरण का दूसरा हिस्सा नहीं है; इसका अर्थ "अपने आह्वान पर" रूप का एक पाठ है, जो अभिव्यक्ति के दृष्टिकोण से बहुत अच्छा नहीं है; सरल मामलों में, कॉपी-पेस्ट "जब इसे कहा जाता है" विशेष रूप से लाभदायक नहीं है, तो IMHO।

वर्णन ब्लॉक में, प्रारंभिक कार्य (कार्य की इकाई, यूओडब्ल्यू) का विवरण आमतौर पर रखा जाता है। इस ब्लॉक में शब्द " कार्य की इकाई - परिदृश्य / संदर्भ - अपेक्षित व्यवहार " पैटर्न के साथ जारी रहना चाहिए जो वर्णन में शुरू हुआ:
[ ] [ / ] ( | ) [ ]

या एक कोड के रूप में:

 describe('[unit of work]', () => { it(' [ ] / [/]', () => { }); }); 

यदि कई परीक्षण समूह एक ही स्क्रिप्ट का अनुसरण करते हैं या एक ही संदर्भ में फिट होते हैं, तो आप वर्णन किए गए नेस्टेड ब्लॉक का उपयोग कर सकते हैं।

 describe('[unit of work]', () => { describe('// [scenario/context]', () => { it('/ [expected behaviour]', () => { }); }); }); describe(' Gallery', () => { describe(' ', () => { it('    ', () => { }); it('    ', () => { }); }); // ... }); 

वन टेस्ट - वन प्रोब्लम

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

BAD उदाहरण:

 describe('isUndefined function', ()=> { it('  true or false    undefined', () => { expect(isUndefined(undefined)).toEqual(true); expect(isUndefined(true)).toEqual(false); }); }); 

इस ब्लॉक में दो अपेक्षित ब्लॉक हैं। इसका अर्थ है कि डेवलपर, इस परीक्षण के नकारात्मक परिणाम को देखकर, यह निर्धारित नहीं कर पाएगा कि उसके कोड में क्या गलत है और इसे कैसे ठीक किया जाए।

अच्छा उदाहरण:

 describe('isUndefined function', ()=> { it('  true,    undefined', () => { expect(isUndefined(undefined)).toEqual(true); }); it('  false      ', () => { expect(isUndefined(true)).toEqual(false); }); }); 

ऊपर दिए गए उदाहरण में प्रत्येक परीक्षण एक विशिष्ट समस्या का मूल्यांकन करता है। इसके अलावा, परीक्षण विवरण स्पष्ट रूप से बताता है कि किस मामले में इसे पारित किया जाएगा। कंसोल में दोनों मामलों में, डेवलपर परीक्षण किए गए उपयोगकर्ता कार्यक्षमता से कार्यों / शर्तों के तहत क्या परिणाम अपेक्षित हैं, इसकी एक सूची में पढ़ेंगे।

परीक्षण व्यवहार

तस्वीर को देखो, स्ट्रोक को मत देखो। टेस्ट कस्टम स्क्रिप्ट / व्यवहार, कार्यान्वयन विवरण नहीं। फिर कार्यान्वयन विवरण बदलने से परीक्षण के परिणाम प्रभावित नहीं होंगे। एक नकारात्मक परीक्षा परिणाम को इंगित करना चाहिए कि क्या कार्यक्रम उपयोगकर्ता के दृष्टिकोण से सही ढंग से व्यवहार करता है। परीक्षण को कार्यान्वयन विवरणों को नियंत्रित / सीमित नहीं करना चाहिए।

BAD उदाहरण:

 it('   discovery  ', () => { discoveriesCache.addDiscovery('57463', 'John'); expect(discoveriesCache._discoveries[0].id).toBe('57463'); expect(discoveriesCache._discoveries[0].name).toBe('John'); }); 

यहाँ क्या बुरा है? सबसे पहले, दो ब्लॉक की उम्मीद करते हैं, लेकिन यह मुख्य बात नहीं है। दूसरे, यह व्यवहार का परीक्षण नहीं है, लेकिन कार्यान्वयन विवरण है। कार्यान्वयन विवरण बदल जाएगा (निजी क्षेत्रों का नाम बदल दिया जाता है) - परीक्षण अमान्य हो जाएगा और फिर से लिखना होगा।

अच्छा उदाहरण:

 it('   discovery  ', () => { discoveriesCache.addDiscovery('57463', 'John'); expect(discoveriesCache.isDiscoveryExist('57463', 'John')).toBe(true); }); 

यह उदाहरण एक सार्वजनिक एपीआई का परीक्षण करता है जो यथासंभव स्थिर होना चाहिए।

एक ट्रांसलेटर से निष्कर्ष

"Onegin एक पेडेंट था ..." मुझे लगता है कि अधिकांश डेवलपर्स परीक्षण नामों की सटीकता और पठनीयता पर थोड़ा ध्यान देते हैं। अक्सर मैं "यह कोड क्या करता है" या "यह कोड क्यों करता है" जैसी लंबी चर्चाओं का अवलोकन करता है। यह जेएस में मुख्य कोड (अस्पष्ट, मॉड्यूल, सेवाओं, कार्यों और चर के फजी नामों), और परीक्षणों (धुंधले मामलों, परीक्षण विवरणों, फजी विवरणों) पर लागू होता है। यह सब इस तथ्य की ओर जाता है कि कोड वह नहीं है जो अपेक्षित है।

अपने एक साक्षात्कार में, डेविड हेनीमियर हैन्सन (रेल ढांचे के निर्माता) ने कुछ इस तरह कहा:
"यूनिट परीक्षण केवल दिखाते हैं कि आपका कार्यक्रम अपेक्षित चीज़%: ओ कर रहा है।"

उनका मतलब था कि व्यवहार का परीक्षण होना चाहिए, न कि कोड इकाइयों का। और शाब्दिक भाषा में एक व्यवहारिक पैटर्न होना चाहिए। यानी "एंटिटी ए को इस तरह की और ऐसी परिस्थितियों में इस तरह का व्यवहार करना चाहिए।" प्रपत्र की एक श्रृंखला का वर्णन [- वर्णन ] - यह - उम्मीद है कि इस तरह के एक तह निर्माण में बदलना चाहिए।

आपका ध्यान के लिए धन्यवाद!