👩🏾‍🤝‍👨🏻 💉 🥫 यूनिट परीक्षण लिखते समय अप्रिय त्रुटियां 🈴 🕴️ ↙️

दूसरे दिन, मैं एक आंतरिक रिपोर्ट बनाऊंगा जिसमें मैं अपने डेवलपर्स को उन अप्रिय गलतियों के बारे में बताऊंगा जो यूनिट टेस्ट लिखते समय हो सकती हैं। मेरे दृष्टिकोण से सबसे अप्रिय त्रुटियां तब होती हैं जब परीक्षण पास हो जाते हैं, लेकिन साथ ही वे ऐसा गलत तरीके से करते हैं कि पास न करना बेहतर होगा। और मैंने ऐसी त्रुटियों के उदाहरण सभी के साथ साझा करने का निर्णय लिया। इस क्षेत्र से निश्चित रूप से कुछ और बताना है। उदाहरण Node.JS और Mocha के लिए लिखे गए हैं, लेकिन सामान्य तौर पर ये त्रुटियां किसी अन्य पारिस्थितिकी तंत्र के लिए सही हैं।

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

तो चलिए चलते हैं।

0. परीक्षणों की कमी

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

1. चल रहे परीक्षणों की कमी

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

2. कवरेज का अभाव

यदि आप अभी भी नहीं जानते हैं कि परीक्षणों में क्या कवरेज है, तो अभी जाने और पढ़ने का समय है। कम से कम विकिपीडिया । अन्यथा, एक अच्छा मौका है कि आपका परीक्षण 10% कोड की जांच करेगा जो आपको लगता है कि यह जांच करता है। जल्दी या बाद में आप निश्चित रूप से उस पर कदम रखेंगे। बेशक, यहां तक कि कोड का 100% कवरेज किसी भी तरह से इसकी पूर्ण शुद्धता की गारंटी नहीं देता है - लेकिन यह कवरेज की कमी से बहुत बेहतर है क्योंकि यह आपको अधिक संभावित त्रुटियां दिखाएगा। कोई आश्चर्य नहीं कि Node.JS के नवीनतम संस्करणों में भी इसे पढ़ने के लिए अंतर्निहित उपकरण हैं। सामान्य तौर पर, कवरेज का विषय गहरा और अत्यंत समग्र होता है, लेकिन मैं इसमें बहुत गहराई तक नहीं जाता - मैं बहुत कुछ कहना चाहता हूं।

3।

const {assert} = require('chai'); const Promise = require('bluebird'); const sinon = require('sinon'); class MightyLibrary { static someLongFunction() { return Promise.resolve(1); // just imagine a really complex and long function here } } async function doItQuickOrFail() { let res; try { res = await MightyLibrary.someLongFunction().timeout(1000); } catch (err) { if (err instanceof Promise.TimeoutError) { return false; } throw err; } return res; } describe('using Timeouts', ()=>{ it('should return false if waited too much', async ()=>{ // stub function to emulate looong work sinon.stub(MightyLibrary, 'someLongFunction').callsFake(()=>Promise.delay(10000).then(()=>true)); const res = await doItQuickOrFail(); assert.equal(res, false); }); });

यहाँ क्या गलत है

यूनिट टेस्ट में टाइमआउट।

यहां वे जांचना चाहते थे कि लंबे ऑपरेशन के लिए टाइमआउट सेट करना वास्तव में काम करता है। सामान्य तौर पर, यह कुछ भी समझ में नहीं आता है - आपको मानक पुस्तकालयों की जांच नहीं करनी चाहिए - लेकिन यह कोड एक और समस्या की ओर जाता है - एक सेकंड के लिए परीक्षणों के निष्पादन समय को बढ़ाने के लिए। ऐसा लगता है कि यह इतना अधिक नहीं है ... लेकिन प्रति दिन लॉन्च की संख्या से, डेवलपर्स की संख्या से समान परीक्षणों की संख्या से इस दूसरे को गुणा करें ... और आप समझेंगे कि ऐसे समय के कारण आप दैनिक नहीं, तो कई घंटे काम के साप्ताहिक खो सकते हैं।

4।

 const fs = require('fs'); const testData = JSON.parse(fs.readFileSync('./testData.json', 'utf8')); describe('some block', ()=>{ it('should do something', ()=>{ someTest(testData); }) })

यहाँ क्या गलत है

परीक्षण ब्लॉक के बाहर परीक्षण डेटा लोड हो रहा है।

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

5।

 const {assert} = require('chai'); const sinon = require('sinon'); class Dog { // eslint-disable-next-line class-methods-use-this say() { return 'Wow'; } } describe('stubsEverywhere', ()=>{ before(()=>{ sinon.stub(Dog.prototype, 'say').callsFake(()=>{ return 'meow'; }); }); it('should say meow', ()=>{ const dog = new Dog(); assert.equal(dog.say(), 'meow', 'dog should say "meow!"'); }); });

यहाँ क्या गलत है

कोड वास्तव में स्टब्स द्वारा प्रतिस्थापित किया गया है।

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

6।

 const sinon = require('sinon'); const {assert} = require('chai'); class Widget { fetch() {} loadData() { this.fetch(); } } if (!sinon.sandbox || !sinon.sandbox.stub) { sinon.sandbox = sinon.createSandbox(); } describe('My widget', () => { it('is awesome', () => { const widget = new Widget(); widget.fetch = sinon.sandbox.stub().returns({ one: 1, two: 2 }); widget.loadData(); assert.isTrue(widget.fetch.called); }); });

यहाँ क्या गलत है

परीक्षणों के बीच निर्भरता।

पहली नज़र में यह स्पष्ट है कि वे यहाँ लिखना भूल गए
  afterEach(() => { sinon.sandbox.restore(); }); 
लेकिन समस्या केवल यही नहीं है, बल्कि एक ही सैंडबॉक्स का उपयोग सभी परीक्षणों के लिए किया जाता है। और परीक्षण निष्पादन वातावरण को इस तरह से भ्रमित करना बहुत आसान है कि वे एक-दूसरे पर निर्भर होने लगते हैं। उसके बाद, परीक्षण केवल एक निश्चित क्रम में किया जाना शुरू हो जाएगा, और सामान्य तौर पर यह स्पष्ट नहीं होगा कि क्या परीक्षण करना है।

सौभाग्य से, कुछ बिंदु पर sinon.sandbox को पदावनत और बाहर काट दिया गया था, इसलिए आप केवल एक विरासत परियोजना पर इस तरह की समस्या का सामना कर सकते हैं - लेकिन परीक्षण निष्पादन पर्यावरण को इस तरह से भ्रमित करने के लिए कई अन्य तरीके हैं ताकि बाद में जांच करने के लिए दर्दनाक रूप से दर्दनाक हो। कौन सा कोड गलत व्यवहार का दोषी है। वैसे, हाल ही में हब पर "आइस फैक्ट्री" जैसे किसी टेम्पलेट के बारे में एक पोस्ट थी - यह एक रामबाण नहीं है, लेकिन कभी-कभी यह ऐसे मामलों में मदद करता है।

7. परीक्षण फ़ाइल में विशाल परीक्षण डेटा

बहुत बार मैंने देखा कि कितनी बड़ी JSON फाइलें, और यहां तक कि XML, सीधे परीक्षण में रखना। मुझे लगता है कि यह स्पष्ट है कि ऐसा करने लायक क्यों नहीं है - यह देखने, संपादित करने के लिए दर्दनाक हो जाता है, और कोई भी आईडीई इसके लिए आपको धन्यवाद नहीं देगा। यदि आपके पास बड़ा परीक्षण डेटा है, तो इसे परीक्षण फ़ाइल से बाहर निकालें।

8।

 const {assert} = require('chai'); const crypto = require('crypto'); describe('extraTests', ()=>{ it('should generate unique bytes', ()=>{ const arr = []; for (let i = 0; i < 1000; i++) { const value = crypto.randomBytes(256); arr.push(value); } const unique = arr.filter((el, index)=>arr.indexOf(el) === index); assert.equal(arr.length, unique.length, 'Data is not random enough!'); }); });

यहाँ क्या गलत है

अतिरिक्त परीक्षण।

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

खैर, परीक्षण में यादृच्छिक मूल्यों के लिए टाई अपने आप में खरोंच से अस्थिर परीक्षण करके अपने आप को पैर में गोली मारने का एक शानदार तरीका है।

9. मोक की कमी

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

11।

 const {assert} = require('chai'); class CustomError extends Error { } function mytestFunction() { throw new CustomError('important message'); } describe('badCompare', ()=>{ it('should throw only my custom errors', ()=>{ let errorHappened = false; try { mytestFunction(); } catch (err) { errorHappened = true; assert.isTrue(err instanceof CustomError); } assert.isTrue(errorHappened); }); });

यहाँ क्या गलत है

जटिल त्रुटि डिबगिंग।

सब कुछ खराब नहीं है, लेकिन एक समस्या है - यदि परीक्षण अचानक दुर्घटनाग्रस्त हो जाता है, तो आपको फॉर्म की एक त्रुटि दिखाई देगी

1) badCompare should throw only my custom errors: AssertionError: expected false to be true + expected - actual -false +true at Context.it (test/011_badCompare/test.js:23:14)

इसके अलावा, यह समझने के लिए कि वास्तव में किस तरह की त्रुटि हुई है - आपको परीक्षण को फिर से लिखना होगा। तो एक अप्रत्याशित त्रुटि के मामले में - परीक्षण के बारे में बात करने की कोशिश करें, और न केवल तथ्य यह है कि ऐसा हुआ।

12।

 const {assert} = require('chai'); function someVeryBigFunc1() { return 1; // imagine a tonn of code here } function someVeryBigFunc2() { return 2; // imagine a tonn of code here } describe('all Before Tests', ()=>{ let res1; let res2; before(async ()=>{ res1 = await someVeryBigFunc1(); res2 = await someVeryBigFunc2(); }); it('should return 1', ()=>{ assert.equal(res1, 1); }); it('should return 2', ()=>{ assert.equal(res2, 2); }); });

यहाँ क्या गलत है

पहले ब्लॉक में सब कुछ।

ऐसा लगता है कि एक शांत दृष्टिकोण `ऑपरेशन` से पहले सभी कार्यों को करना है, और इस तरह से यह` `के अंदर केवल जांच छोड़ देता है।
वास्तव में नहीं।
क्योंकि इस मामले में एक गड़बड़ है जिसमें आप न तो परीक्षणों के वास्तविक निष्पादन के समय को समझ सकते हैं, न ही पतन का कारण, और न ही एक परीक्षण से संबंधित है, और दूसरे से क्या।
तो परीक्षण के सभी काम (मानक इनिशियलाइज़ेशन को छोड़कर) परीक्षण के अंदर ही किए जाने चाहिए।

13।

 const {assert} = require('chai'); const moment = require('moment'); function someDateBasedFunction(date) { if (moment().isAfter(date)) { return 0; } return 1; } describe('useFutureDate', ()=>{ it('should return 0 for passed date', ()=>{ const pastDate = moment('2010-01-01'); assert.equal(someDateBasedFunction(pastDate), 0); }); it('should return 1 for future date', ()=>{ const itWillAlwaysBeInFuture = moment('2030-01-01'); assert.equal(someDateBasedFunction(itWillAlwaysBeInFuture), 1); }); });

यहाँ क्या गलत है

तारीखों पर बाँध।

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

याद रखें कि कोई भी तारीख जल्द या बाद में आएगी - इसलिए या तो 'sinon.fakeTimers` जैसी चीजों के साथ समय के अनुकरण का उपयोग करें, या 2050 जैसी कम से कम दूरस्थ तिथियों को सेट करें - अपने वंशजों को चोट लगने दें ...

14।

 describe('dynamicRequires', ()=>{ it('should return english locale', ()=>{ // HACK : // Some people mutate locale in tests to chinese so I will require moment here // eslint-disable-next-line global-require const moment = require('moment'); const someDate = moment('2010-01-01').format('MMMM'); assert.equal(someDate, 'January'); }); });

यहाँ क्या गलत है

मॉड्यूल की गतिशील लोडिंग।

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

15।

 function someComplexFunc() { // Imagine a piece of really strange code here return 1; } describe('cryptic', ()=>{ it('success', ()=>{ const result = someComplexFunc(); assert.equal(result, 1); }); it('should not fail', ()=>{ const result = someComplexFunc(); assert.equal(result, 1); }); it('is right', ()=>{ const result = someComplexFunc(); assert.equal(result, 1); }); it('makes no difference for solar system', ()=>{ const result = someComplexFunc(); assert.equal(result, 1); }); });

यहाँ क्या गलत है

असंगत परीक्षण नाम।

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

16।

 const {assert} = require('chai'); const Promise = require('bluebird'); function someTomeoutingFunction() { throw new Promise.TimeoutError(); } describe('no Error check', ()=>{ it('should throw error', async ()=>{ let timedOut = false; try { await someTomeoutingFunction(); } catch (err) { timedOut = true; } assert.equal(timedOut, true); }); });

यहाँ क्या गलत है

फेंकी गई त्रुटि के सत्यापन का अभाव।

अक्सर आपको यह जांचने की आवश्यकता होती है कि किसी मामले में फ़ंक्शन एक त्रुटि फेंकता है। लेकिन आपको हमेशा यह जांचने की आवश्यकता है कि क्या ये वो डोरियाँ हैं जिनकी हम तलाश कर रहे हैं - क्योंकि यह अचानक पता चल सकता है कि एक और त्रुटि एक और जगह और अन्य कारणों से बाहर फेंक दी गई थी ...

17।

 function someBadFunc() { throw new Error('I am just wrong!'); } describe.skip('skipped test', ()=>{ it('should be fine', ()=>{ someBadFunc(); }); });

यहाँ क्या गलत है

विकलांग परीक्षण।

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

यहाँ इस तरह का चयन किया गया है। ये सभी परीक्षण अच्छी तरह से पास करते हैं, लेकिन वे डिजाइन से टूट जाते हैं। टिप्पणियों में अपने विकल्प जोड़ें, या ऐसी गलतियों को इकट्ठा करने के लिए किए गए भंडार में ।

यूनिट परीक्षण लिखते समय अप्रिय त्रुटियां

0. परीक्षणों की कमी

1. चल रहे परीक्षणों की कमी

2. कवरेज का अभाव

3।

4।

5।

6।

7. परीक्षण फ़ाइल में विशाल परीक्षण डेटा

8।

9. मोक की कमी

11।

12।

13।

14।

15।

16।

17।

More articles: