लाभ:
- स्वीकृति नियम से स्वतंत्र रूप से यूनिट परीक्षणों में अपेक्षित मूल्य की गणना करके कृत्रिम बुद्धिमत्ता को गलत व्यवहार को 'सही' मानने से रोकने की क्षमता
- AAA और FIRST सिद्धांतों को लागू करके और बाहरी निर्भरता का मज़ाक उड़ाकर तेज़, स्वतंत्र और दोहराए जाने वाले परीक्षणों को प्रिंट करने की क्षमता
- उत्परिवर्तन (कोड ब्रेकिंग) के साथ परीक्षणों का परीक्षण करने और डिज़ाइन गंध के रूप में परीक्षण करने में कठिन कोड को पहचानने की क्षमता
परीक्षण पिरामिड की सबसे बड़ी और सबसे तेज़ परत इकाई परीक्षण है - परीक्षण जो किसी फ़ंक्शन या कोड के छोटे टुकड़े को बाकी सभी चीजों से अलग करके सत्यापित करता है। हजारों यूनिट परीक्षण कुछ ही सेकंड में चलते हैं और बग पकड़ लेते हैं जबकि कोड अभी भी डेवलपर की स्क्रीन पर होता है। यूनिट परीक्षण तैयार करने में आर्टिफिशियल इंटेलिजेंस (एआई) शायद सबसे अधिक कुशल है: आप इसे एक फ़ंक्शन देते हैं, एआई दर्जनों परीक्षण तैयार करता है। लेकिन यही सुविधा सबसे बड़े जाल को जन्म देती है: एआई आसानी से ऐसे परीक्षण तैयार करता है जो "हरित चमकते हैं लेकिन कुछ भी सत्यापित नहीं करते" या कोड के वर्तमान (शायद दोषपूर्ण) व्यवहार को "सही" के रूप में स्वीकार करते हैं। इस इकाई में आप सीखेंगे कि एआई के साथ वास्तव में सुरक्षात्मक इकाई परीक्षण कैसे लिखें और परीक्षण योग्य कोड और एआई के बीच संबंध कैसे बनाएं।
एक अच्छे इकाई परीक्षण के गुण: प्रथम
अच्छे यूनिट परीक्षण पहले सिद्धांतों का पालन करते हैं: तेज़, स्वतंत्र (परीक्षण एक-दूसरे पर निर्भर नहीं होने चाहिए), दोहराने योग्य (दोहराने योग्य - किसी भी वातावरण में समान परिणाम), स्व-सत्यापन (स्पष्ट पास/असफल), समय पर (समय पर)। एआई द्वारा परीक्षण कराते समय स्वयं को इन सिद्धांतों की याद दिलाएं; विशेष रूप से पूछें कि परीक्षण "स्वतंत्र" और "दोहराने योग्य" होने के लिए बाहरी दुनिया (वास्तविक डेटाबेस, नेटवर्क, घड़ी) पर निर्भर न हो।
एएए पैटर्न और अभिव्यंजक जोर
एक ठोस इकाई परीक्षण एएए संरचना का अनुसरण करता है: व्यवस्थित करें (तैयार करें - इनपुट और निर्भरता सेट करें), अधिनियम (निष्पादित करें - परीक्षण के तहत फ़ंक्शन को कॉल करें), जोर दें (मान्य करें - अपेक्षित मूल्य के साथ परिणाम की तुलना करें)। आलोचनात्मक एक मुखर है. एआई द्वारा की जाने वाली सबसे आम गलती परीक्षण के तहत कोड के आउटपुट से दावा प्राप्त करना है - "जो भी कोड लौटाता है वह सत्य है" तर्क। इससे परीक्षण निरर्थक हो जाता है। सही तरीका अपेक्षित मूल्य को स्वतंत्र रूप से निर्धारित करना है (स्वीकृति मानदंड से, इसे मैन्युअल रूप से गणना करें)।
ध्यान दें: यदि आप एआई को "इस फ़ंक्शन के लिए एक परीक्षण लिखें" कहते हैं, तो एआई फ़ंक्शन चला सकता है और इसके आउटपुट को "अपेक्षित" के रूप में लिख सकता है। फ़ंक्शन गलत होने पर भी यह परीक्षण पास हो जाता है। इसके बजाय, कहें "आप इन नियमों के अनुसार अपेक्षित परिणामों की गणना करते हैं, फ़ंक्शन के वर्तमान आउटपुट का संदर्भ न दें।"
मॉक, स्टब्स और निर्भरताएँ
इकाई परीक्षण के लिए अलगाव की आवश्यकता होती है। यदि आपका फ़ंक्शन किसी डेटाबेस या एपीआई पर निर्भर करता है, तो परीक्षण में उन्हें नकली ऑब्जेक्ट (मॉक/स्टब - वास्तविक निर्भरता के लिए एक नियंत्रित, डमी विकल्प) से बदल दिया जाता है। यह परीक्षण को तीव्र, स्वतंत्र और प्रतिलिपि प्रस्तुत करने योग्य बनाता है। एआई मॉक इंस्टालेशन तैयार कर सकता है; लेकिन अत्यधिक मजाक उड़ाने से सावधान रहें: यदि आप हर चीज का मजाक उड़ाते हैं, तो परीक्षण केवल "नकली परिणाम क्या देता है" सत्यापित करेगा, वास्तविक तर्क नहीं। संतुलन: बाहरी दुनिया का अनुकरण करें, परीक्षण के तहत वास्तविक तर्क पर अमल करें।
टेस्टेबिलिटी और एआई
एक दिलचस्प प्रतिक्रिया है: जिस कोड का परीक्षण करना कठिन होता है वह अक्सर खराब तरीके से डिज़ाइन किया गया कोड होता है। यदि एआई को किसी फ़ंक्शन (बहुत अधिक निर्भरता, छिपी हुई वैश्विक स्थिति, साइड इफेक्ट्स) के लिए परीक्षण लिखने में परेशानी होती है, तो यह एक डिज़ाइन गंध है। एआई से यह पूछने पर कि "आप इस कोड को परीक्षण योग्य बनाने के लिए इसे कैसे रिफैक्टर करेंगे" बेहतर परीक्षण और बेहतर कोड दोनों की ओर ले जाता है।
पैरामीटरयुक्त परीक्षण और डेटा विविधता
अलग-अलग इनपुट के साथ एक ही नियम को सत्यापित करने के लिए हर बार एक अलग परीक्षण लिखना कठिन और बनाए रखना कठिन है। पैरामीटरयुक्त परीक्षण - एक संरचना जो इनपुट और अपेक्षित परिणामों की सूची पर एक ही परीक्षण तर्क को बार-बार चलाती है - इस पुनरावृत्ति को समाप्त करती है: एक एकल परीक्षण निकाय को दर्जनों इनपुट जोड़े के साथ खिलाया जाता है। जब आप इसे अपने स्वीकृति नियम देते हैं तो एआई इन इनपुट-अपेक्षित परिणाम तालिकाओं को तैयार करने में बहुत कुशल होता है; विशेष रूप से, यह सीमा मानों और तुल्यता वर्गों को व्यवस्थित रूप से सारणीबद्ध करता है।
लेकिन यहां भी एक जाल है: एआई परीक्षण के तहत कोड से उत्पन्न तालिका में अपेक्षित परिणाम प्राप्त करता है। पैरामीटरयुक्त परीक्षण में यह त्रुटि और भी खतरनाक है, क्योंकि एक भी गलत तर्क दर्जनों पंक्तियों को अमान्य कर देता है। इसलिए, हमेशा अपेक्षित परिणाम कॉलम की गणना स्वीकृति नियम के अनुसार स्वतंत्र रूप से करें और कम से कम कुछ पंक्तियों को मैन्युअल रूप से मान्य करें। विवरण कॉलम "प्रत्येक पंक्ति क्या दर्शाती है" के लिए भी पूछें; इसलिए जब कोई पंक्ति टूटती है तो आप तुरंत देख सकते हैं कि कौन सी स्थिति टूटी है।
युक्ति: जानबूझकर पैरामीटरयुक्त परीक्षण तालिका में एक "ट्रैप पंक्ति" जोड़ें - अर्थात, जानबूझकर परिणाम को गलत टाइप करें। यदि आपके परीक्षण चलाने पर वह रेखा लाल नहीं होती है, तो आपका परीक्षण वास्तव में उस स्थिति की पुष्टि नहीं कर रहा है। यह एक त्वरित मॉक-पास जांच है।
कमजोर संकेत/मजबूत संकेत
कमज़ोर: "इस फ़ंक्शन के लिए एक इकाई परीक्षण लिखें।"
मजबूत: "टैक्सकैलकुलेट (राशि, दर) फ़ंक्शन के लिए [भाषा/ढांचा] इकाई परीक्षण लिखें। स्वीकृति नियम: परिणाम = राशि * दर, 2 दशमलव तक पूर्णांकित; नकारात्मक राशि या दर एक त्रुटि फेंकता है; यदि दर 0 है तो 0 लौटाता है। एएए संरचना का उपयोग करें। इन नियमों के अनुसार अपेक्षित मूल्यों की मैन्युअल रूप से गणना करें; फ़ंक्शन के वर्तमान आउटपुट का संदर्भ न दें। बाउंड और नकारात्मक मामलों को कवर करें (0, नकारात्मक, बहुत बड़ा, दशमलव तक गोल)। प्रत्येक परीक्षण के नाम का वर्णन करें यह नियम बाहरी निर्भरता "नहीं" की पुष्टि करता है।
शक्तिशाली संकेत; यह स्वीकृति नियम, स्वतंत्र अपेक्षित मूल्य अपेक्षा, संरचना और किनारे के मामले देता है। इस प्रकार, परीक्षण नियम का संरक्षक बन जाता है, न कि संहिता का दर्पण।
यूनिट परीक्षण गुणवत्ता तालिका
लक्षण
ख़राब परीक्षण (नकली-विश्वास)
अच्छा परीक्षण
जोर देना
कोई नहीं या "शून्य नहीं"
अपेक्षित ठोस मूल्य
अपेक्षित मूल्य स्रोत
फ़ंक्शन का आउटपुट
स्वीकृति नियम/मैन्युअल गणना
लत
वास्तविक डीबी/नेटवर्क/घंटा
मॉक/स्टब से इंसुलेटेड
किनारे का मामला
केवल मंगलमय मार्ग
सीमा, नकारात्मक, त्रुटि
जब आप कोड तोड़ते हैं
हरा रहता है
लाल हो जाता है
नाम
परीक्षण 1, परीक्षण विधि
उस नियम का वर्णन करता है जिसकी वह पुष्टि करता है
चार प्रतिलिपि योग्य टेम्पलेट
1) नियम-संचालित इकाई परीक्षण:
आपकी भूमिका: वरिष्ठ सॉफ्टवेयर परीक्षण इंजीनियर। [भाषा/ढांचे] के साथ निम्नलिखित फ़ंक्शन पर एक इकाई परीक्षण लिखें: [हस्ताक्षर]। स्वीकृति नियम: [नियम]। - एएए संरचना का उपयोग करें। - इन नियमों के अनुसार अपेक्षित मूल्यों की मैन्युअल रूप से गणना करें; फ़ंक्शन के वर्तमान आउटपुट का संदर्भ न दें। - सीमा, नकारात्मक, त्रुटि और खुश पथ को अलग-अलग परीक्षणों से कवर करें। - प्रत्येक परीक्षण नाम को उस नियम का वर्णन करने दें जिसे वह सत्यापित करता है। - बाहरी निर्भरता का अनुकरण करें; वास्तविक तर्क को कार्यान्वित करें।
2) उत्परिवर्तन प्रतिरोध नियंत्रण:
इन यूनिट परीक्षणों की जाँच करें। 5 छोटे बदलावों की सूची बनाएं जो मैं परीक्षण के तहत कोड में कर सकता हूं (ए - ए + के बजाय, ए > = के बजाय ए >, एक सीमा बदलाव) और मुझे प्रत्येक के लिए बताएं कि इनमें से कौन सा परीक्षण लाल हो जाएगा? यदि कोई भी नहीं लौटाया जाता है, तो परीक्षण अपर्याप्त है। कोड + परीक्षण: [पेस्ट करें]
3) परीक्षण योग्यता समीक्षा:
इस फ़ंक्शन के लिए यूनिट परीक्षण लिखना कठिन क्यों है? छिपी हुई लत, वैश्विक स्थिति, दुष्प्रभाव, क्या कई जिम्मेदारियाँ हैं? इसे परीक्षण योग्य बनाने के लिए न्यूनतम रिफैक्टरिंग का सुझाव दें; व्यवहार मत बदलो. कोड: [चिपकाएं]
4) अपूर्ण परिदृश्य पूर्णता:
निम्नलिखित फ़ंक्शन और उपलब्ध परीक्षण दिए गए हैं। सूचीबद्ध करें कि किस व्यवहार/एजकेस का कभी परीक्षण नहीं किया गया है (स्कोप गैप) और प्रत्येक के लिए एक परीक्षण जोड़ें। फ़ंक्शन+परीक्षण: [पेस्ट करें]
तीन मिनी मामले
केस 1 - कोड को मिरर करने का परीक्षण करें। एक डेवलपर ने AI से राउंडिंग फ़ंक्शन के लिए एक परीक्षण लिखवाया था; 10 परीक्षण हरे थे. वास्तव में, फ़ंक्शन गलत दिशा में घूम रहा था, लेकिन एआई ने फ़ंक्शन के आउटपुट से अपेक्षित मान ले लिया था, इसलिए परीक्षणों ने त्रुटि को "सही" माना। जब अपेक्षित मानों की मैन्युअल रूप से "नियम-संचालित" टेम्पलेट के साथ गणना की गई, तो 4 परीक्षण लाल हो गए और वास्तविक त्रुटि सामने आई।
केस 2 - उत्परिवर्तन नियंत्रण का मूल्य। एक टीम ने 45 यूनिट परीक्षणों पर भरोसा किया। "उत्परिवर्तन मजबूती जांच" के साथ कोड में 20 छोटे बदलाव करने का प्रयास किया गया; परीक्षणों में उनमें से केवल 11 ही पकड़े गए। शेष 9 व्यवधान चुपचाप बीत गए। टीम ने कमजोर परीक्षणों को मजबूत किया; अगली रिलीज़ में इन उन्नत परीक्षणों द्वारा एक वास्तविक गणना त्रुटि पकड़ी गई।
केस 3 - अपरीक्षणशीलता एक डिज़ाइन गंध है। एआई ऑर्डरिंग फ़ंक्शन के लिए परीक्षण नहीं लिख सका, उसे लगातार वास्तविक डेटाबेस की आवश्यकता थी। "परीक्षणशीलता समीक्षा" टेम्पलेट से पता चला कि फ़ंक्शन एम्बेडेड डेटाबेस एक्सेस है। जब निर्भरता इंजेक्शन हटा दिया गया, तो परीक्षण लिखे जा सके और कोड साफ़ हो गया।
सामान्य गलतियाँ
- कोड से अपेक्षित मूल्य प्राप्त करना। एआई फ़ंक्शन आउटपुट को "सही" के रूप में स्वीकार करता है; परीक्षण जो दोषपूर्ण कोड की पुष्टि करता है।
- बिना दावे के या तुच्छ दावे के साथ परीक्षण करें। "उसने कोई त्रुटि नहीं की, वह उत्तीर्ण हो गया" तर्क; यह किसी बात की पुष्टि नहीं करता.
- अत्यधिक उपहास. हर चीज़ का मज़ाक उड़ाना और केवल वही परीक्षण करना जो नकली परिणाम देता है; वास्तविक तर्क का परीक्षण नहीं किया जाता है।
- बस ख़ुशहाल सड़क. सीमा, नकारात्मक और त्रुटि स्थितियों को दरकिनार करना।
- कोड तोड़कर परीक्षण नहीं। म्यूटेशन की जांच किए बिना हरे पर भरोसा करना।
- अप्राप्यता को नजरअंदाज करना. कठिन परीक्षण पर ज़ोर देने के बजाय ख़राब डिज़ाइन को पहचानना और उसे ठीक न करना।
संक्षेप में
यूनिट परीक्षण परीक्षण पिरामिड की सबसे तेज़ और सबसे बड़ी परत हैं; यह सबसे सस्ते क्षण में गलती पकड़ लेता है। एआई इकाई परीक्षण तैयार करने में बहुत सक्षम है, लेकिन इसका सबसे बड़ा नुकसान ऐसे परीक्षण लिखना है जो कोड से अपेक्षित मूल्य प्राप्त करके गलत व्यवहार को "सही" मानते हैं। समाधान: स्वीकृति नियम दें, अपेक्षित मानों की मैन्युअल रूप से गणना करें, AAA और FIRST सिद्धांतों को लागू करें, बाहरी दुनिया का मजाक उड़ाएं और वास्तविक तर्क चलाएं, और उत्परिवर्तन (कोड को तोड़कर) द्वारा प्रत्येक परीक्षण का परीक्षण करें। जिस कोड का परीक्षण करना कठिन है वह एक डिज़ाइन संकेत है जिसे ठीक करने की आवश्यकता है।
आवेदन कार्य
एक ऐसा फ़ंक्शन चुनें जिसमें आपके अपने प्रोजेक्ट से एक व्यावसायिक नियम शामिल हो। स्वीकृति नियम लिखें और "नियम-संचालित इकाई परीक्षण" टेम्पलेट के साथ एआई लेखन परीक्षण करें; अपेक्षित मानों की गणना मैन्युअल रूप से करें। फिर "म्यूटेशन मजबूती जांच" लागू करें: कोड में कम से कम 5 छोटे ब्रेक बनाएं और मापें कि कितने परीक्षण लाल हो गए। पकड़ में न आए भ्रष्टाचारों के लिए नया परीक्षण जोड़ें। रिपोर्ट करें कि कितने व्यवधान पकड़े गए (जैसे उत्परिवर्तन स्कोर)।
जांच सूची
- [ ] मैंने स्वीकृति नियम दिए और अपेक्षित मूल्यों की गणना मैन्युअल रूप से की।
- [ ] मैंने सुनिश्चित किया कि परीक्षणों को कोड से अपेक्षित मूल्य नहीं मिला।
- [ ] मैंने एएए और फर्स्ट दिशानिर्देशों का पालन करते हुए स्वतंत्र परीक्षण स्थापित किया है।
- [ ] मैंने बाहरी निर्भरताओं का मज़ाक उड़ाया और वास्तविक तर्क चलाया।
- [ ] मैंने सीमा, नकारात्मक और त्रुटि मामलों को कवर किया।
- [ ] कोड (म्यूटेशन) को तोड़कर मैंने साबित कर दिया कि परीक्षण वास्तव में रक्षा करते हैं।