🎳 🆎 👩‍🔧 10 मिनट के 10 चरणों में परीक्षण लिखना कैसे शुरू करें 👶🏾 💮 🚵🏿

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

आपको स्थिति का पता कैसे चला?

तो - यह सब बकवास है। आईटी का दायरा अनंत है, ब्रह्मांड की तरह, बहुत काम हमेशा रहेगा। आप या तो अभी परीक्षण लिखना शुरू कर सकते हैं, या कभी नहीं कर सकते। मैंने 10 चरणों में इसे शुरू करने के बारे में एक छोटी योजना तैयार की, प्रति दिन कदम से कदम, 10 मिनट प्रति कदम। और जब मैं कहता हूं कि "10 मिनट" का मेरा मतलब "3 और एक आधे घंटे" नहीं है, और "अच्छी तरह से, कुछ समय, बेहतर लंबे समय", अर्थात् 600 सेकंड। यदि आपके पास प्रति दिन 600 सेकंड खाली समय नहीं है, तो तुरंत परियोजना, कार्य, पेशा, निवास स्थान (आवश्यक रूप से रेखांकित करें) को बदल दें, क्योंकि यह जीवन नहीं है, लेकिन कुछ प्रकार का कठिन श्रम है। चलो चलते हैं।

1. एक परीक्षण ढांचा चुनना

खरोंच से अपने स्वयं के ढांचे को लिखना शुरू करने की कोशिश न करें - क्या आपको इसकी आवश्यकता है? इष्टतम रूपरेखा चुनने पर एक सप्ताह बिताना (हाँ, मैंने देखा कि योजनाओं में इसके लिए समय का ऐसा अनुमान है) भी बेवकूफी है। यहां आपके लिए नुस्खा है: Google में% भाषा% साइट के लिए सबसे अच्छा परीक्षण ढांचा लिखें: stackoverflow.com। पहले 5 लिंक खोलें। उन लोगों को बंद करें जहां प्रश्न या पहले उत्तर की रेटिंग शून्य के पास है। शेष टैब से, आप पहले से अधिकतम रेटिंग के साथ सुरक्षित रूप से किसी भी अनुशंसित फ्रेमवर्क को ले सकते हैं। 99.5% की संभावना के साथ, यह आपके अनुरूप होगा। चूंकि आप इस चरण पर 3 मिनट पहले ही बिता चुके हैं, शेष 7 को फ्रेमवर्क साइट पर जाने पर खर्च किया जा सकता है और इसके उपयोग के उदाहरण देख सकते हैं। सबसे अधिक संभावना है, वहां सब कुछ सरल और स्पष्ट होगा (अन्यथा वह सिफारिशों के शीर्ष पर नहीं होगा)। लेकिन अगर अचानक नहीं - उसी एल्गोरिथ्म के अनुसार एक और एक चुनें।

2. हम हैलो वर्ल्ड लिखते हैं!

हैलो लिखो , दुनिया! हम सिर्फ थूकते हैं। यहाँ, उदाहरण के लिए, C ++ में।

नमस्ते दुनिया!

#include <iostream> using namespace std; int main() { cout << "Hello world!" << endl; return 0; }

अब दो काम करते हैं।
सबसे पहले, हम प्रदर्शित पाठ की पीढ़ी को अलग-अलग कार्यों में निकालते हैं। हां, दो में। ऐसा इसलिए ताकि बाद में उनका परीक्षण किया जा सके।

नमस्ते दुनिया! फिर से तैयार करने के बाद

 #include <iostream> #include <string> using namespace std; string GetHello() { return "Hello"; } string GetAdressat(string adressat) { return adressat; } int main() { cout << GetHello() + " " + GetAdressat("world") + "!" << endl; return 0; }

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

HelloFunctions.h

 #include <string> using namespace std; string GetHello(); string GetAdressat(string adressat);

HelloFunctions.cpp

 #include "HelloFunctions.h" string GetHello() { return "Hello"; } string GetAdressat(string adressat) { return adressat; }

HelloWorld.cpp

 #include <iostream> #include "HelloFunctions.h" using namespace std; int main() { cout << GetHello() + " " + GetAdressat("world") + "!" << endl; return 0; }

3. हेलो दुनिया से फ्रेमवर्क को कनेक्ट करें!

परियोजना के ढांचे का कनेक्शन संभवतः रूपरेखा वेबसाइट पर बहुत अच्छी तरह से लिखा गया है। या स्टैकओवरफ्लो पर। या हैबे पर। उदाहरण के लिए, मैंने एक बार Google टेस्ट कनेक्शन का वर्णन किया था। आमतौर पर यह सब एक सांकेतिक निष्पादन योग्य एप्लिकेशन (स्क्रिप्ट भाषाओं में - एक अलग स्क्रिप्ट) की एक नई परियोजना बनाने के लिए नीचे आता है, एक फ्रेमवर्क को इसमें शामिल (आयात \ उपयोग) की एक जोड़ी से जोड़ते हुए, परीक्षण कोड को परियोजना से जोड़ते हुए (फाइलों के साथ खुद कोड के साथ) और पुस्तकालय को जोड़ते हुए - यह सब है । यदि आप नहीं मानते हैं कि यह कदम 10 मिनट में किया जा सकता है - Youtube खोलें, खोज में अपने ढांचे का नाम लिखें और लगभग उसी सामग्री के 20 वीडियो देखें जो इसे साबित करते हैं।

4. ढांचे की क्षमताओं को समझना

पहले हमें यह पता लगाना होगा:

एक इकाई परीक्षण कैसे लिखें
यूनिट टेस्ट कैसे चलाएं

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

यहाँ, उदाहरण के लिए, हमारी नमस्ते दुनिया के लिए कुछ परीक्षण! उपरोक्त Google परीक्षण:

 #include "HelloFunctions.h" #include "gtest/gtest.h" class CHelloTest : public ::testing::Test { }; TEST_F(CHelloTest, CheckGetHello) { ASSERT_TRUE(GetHello() == "Hello"); } TEST_F(CHelloTest, GetAdressat) { ASSERT_TRUE(GetAdressat("world") == "world"); ASSERT_FALSE(GetAdressat("not world") == "world"); } int main(int argc, char **argv) { ::testing::InitGoogleTest(&argc, argv); return RUN_ALL_TESTS(); }

5. इस परियोजना के लिए रूपरेखा से कनेक्ट करें

हम पहले से ही जानते हैं कि परियोजना से ढांचे को कैसे जोड़ा जाए। याद रखें, उन्होंने चरण संख्या 3 पर किया था? यह सब काम कर गया। अब इसे एक कॉम्बैट प्रोजेक्ट के लिए करते हैं। SVN \ Git \ TFS \ What-you-there के तहत अपने लिए सभी आवश्यक फ्रेमवर्क फ़ाइलें रखें। एक परीक्षण परियोजना बनाओ। इससे फ्रेमवर्क कनेक्ट करें। अपने उत्पाद की निर्माण प्रक्रिया में परीक्षण परियोजना का निर्माण शामिल करें। डीबग और रिलीज़ कॉन्फ़िगरेशन में बिल्ड की जाँच करें। टेस्ट प्रोजेक्ट को कमिट करें, बिल्ड को बिल्ड सर्वर पर चलाएँ। सब कुछ ठीक होना चाहिए। अपने सहयोगियों को अभी तक एक परीक्षण परियोजना की उपस्थिति के साथ लोड न करें - सबसे पहले, आपने कुछ भी नहीं तोड़ा है, और दूसरी बात, आपके पास अभी तक कुछ भी नहीं है।

6. कुछ सरल परीक्षण

क्या आपको याद है कि हम नमस्ते दुनिया से कैसे ऊपर लाए थे ! बाहरी कोड में कार्यक्षमता का हिस्सा? ध्यान दें कि ये कार्य कैसे किए गए हैं: वे वैश्विक चर, या किसी ऑब्जेक्ट की स्थिति पर, या फ़ाइलों या डेटाबेस से बाहरी डेटा पर निर्भर नहीं होते हैं। परिणाम केवल पारित तर्कों पर निर्भर करता है। अपने प्रोजेक्ट में कुछ ऐसा ही खोजें। निश्चित रूप से आपके पास कहीं न कहीं किसी चीज को परिवर्तित करने के लिए कोई कार्य है, क्रमबद्धता / deserialization, पैकिंग / अनपैकिंग, एन्क्रिप्शन / डिक्रिप्शन, आदि। इस बारे में न सोचें कि आपको कितनी ज़रूरत है और उपयोगी कार्यक्षमता जो आप परीक्षण कर रहे हैं। आपका काम एक साधारण परीक्षण लिखना है, लेकिन एक मुकाबला परियोजना के लिए। दौड़ें, देखें "1 परीक्षा सफलतापूर्वक उत्तीर्ण हुई।"

संयोग से, यह इस स्तर पर है कि बहुत बार संदेहवादियों को अंतर्दृष्टि मिलती है। अचानक यह पता चला है कि सबसे बुनियादी कार्यक्षमता के लिए सबसे सरल परीक्षण - अचानक विफल हो गया। हम कोड में चढ़ते हैं - और अचानक हमें कुछ ऐसा लगता है

 return 12; // TODO: implement later

और यह पता चला कि मुख्य कोड ने अभी तक इस फ़ंक्शन को ऐसे तर्कों के साथ कहा है कि सब कुछ ठीक था, लेकिन किसी भी समय यह बदल सकता है।

7. कुछ और जटिल परीक्षण

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

8. हम एक बग परीक्षण लिख रहे हैं

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

9. पहली बार टीडीडी

नई कार्यक्षमता विकसित करते समय आमतौर पर आपका काम कैसा दिखता है? आप शायद पहले सोचते हैं। फिर आप डिजाइन करते हैं कि आप क्या करेंगे - इंटरफेस, कक्षाओं के नामों को स्केच करें, फिर विधियों के नाम, उन्हें कार्यान्वयन, रन, डीबग से भरें। खैर, लगभग कुछ भी बदलने की जरूरत नहीं है। बस उस समय जब आपके पास पहले से ही इंटरफेस, कक्षाएं और विधियों के नाम हैं, लेकिन अभी तक कोई कार्यान्वयन नहीं है - उनके लिए परीक्षण लिखें। व्याख्यात्मक - विधि कहा जाता है - परिणाम की जाँच की। कृपया ध्यान दें कि पहले से ही इस स्तर पर आप कुछ नामों की असंगति, विधियों में तर्क की कमी या अधिकता, अनावश्यक या लापता निर्भरता, और इसी तरह नोटिस करेंगे। इसी समय, इसे अभी ठीक करने के लिए लगभग बेकार है (कार्यान्वयन अभी तक नहीं लिखा गया है) । आर्किटेक्चर को ठीक किया, परीक्षणों को जोड़ा, लॉन्च किया - असफल परीक्षणों का एक गुच्छा देखा। महान, ऐसा होना चाहिए। हमने एक कार्यान्वयन लिखा, परीक्षणों को चलाया - उनमें से अधिकांश को पारित किया, त्रुटियों को ठीक किया, सभी परीक्षणों को सफलतापूर्वक पारित करने में सफल रहे - अच्छी तरह से किया। क्या आपको लगता है कि यह कितना अच्छा हो गया है, आपको क्या नैतिक संतुष्टि मिली है? यह खेल में कुछ उपलब्धियां हासिल करने की खुशी से मिलता जुलता है। और क्यों? लेकिन क्योंकि यह मापा जा सकता है! "कोड 90% के एक परीक्षण कवरेज के साथ 18 परीक्षण पास करता है" - यह अच्छा लगता है, कूलर की तुलना में बहुत अच्छा है, "सुविधा को लागू किया जा रहा है, मुझे यह थोड़ा अजीब लगा, ऐसा लगता है कि यह दुर्घटना नहीं है"। यह गर्व करने का अधिकार देता है। आप घर जाते हैं - और आप स्पष्ट रूप से समझते हैं कि एक दिन में कुछ उपयोगी था, यह "कुछ" औसत दर्जे का, मूर्त, वास्तविक है।

10. हम CI सर्वर पर परीक्षणों के प्रक्षेपण को तेज करते हैं

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

अंतभाषण

एक सावधानीपूर्वक पाठक यह नोटिस कर सकता है कि सातवें से आठवें तक कहीं शुरू होने वाले बिंदु सबसे अधिक संभावना "10 मिनट एक कदम" शीर्षक में नहीं फिट होंगे। मैं क्या कह सकता हूं? इस बात पर विचार करें कि मैं, एक बुरा व्यक्ति, आपको थोड़ा परेशान कर दिया है। हालाँकि, यदि आप धर्मी आक्रोश के साथ इन बिंदुओं का अभ्यास करते हैं, तो:

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

इसलिए तय करें कि वह इसके लायक था या नहीं।

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

10 मिनट के 10 चरणों में परीक्षण लिखना कैसे शुरू करें