👊🏻 👶🏾 🧔🏿 डमी के लिए यूनिट परीक्षण 🤴 🔐 👩🏾‍🤝‍👨🏿

यहां तक कि अगर आप अपने जीवन में कभी नहीं सोचा है कि आप परीक्षण कर रहे हैं, तो आप इसे करते हैं। आप अपना आवेदन जमा करते हैं, बटन दबाते हैं और जांचते हैं कि परिणाम आपकी अपेक्षाओं को पूरा करता है या नहीं। आवेदन में अक्सर आप "टेस्ट इट " बटन के साथ फॉर्म पा सकते हैं या टेस्टकंट्रोलर या मायसेस्टरटेक्स्टिएंट नामक कक्षाएं।

आप जो करते हैं उसे एकीकरण परीक्षण कहा जाता है। आधुनिक अनुप्रयोग काफी जटिल होते हैं और इनमें कई निर्भरताएँ होती हैं। एकीकरण परीक्षण सत्यापित करता है कि कई सिस्टम घटक एक साथ सही तरीके से काम कर रहे हैं।

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

हमें और गहरे जाने की जरूरत है

पहले, चलो पिछले स्तर तक नीचे जाते हैं और सुनिश्चित करते हैं कि हमारे घटक अलग से सही ढंग से काम करते हैं।

विकिपीडिया की ओर मुड़ें:

इकाई परीक्षण , या इकाई परीक्षण, एक प्रोग्रामिंग प्रक्रिया है जो आपको किसी प्रोग्राम के स्रोत कोड के व्यक्तिगत मॉड्यूल की शुद्धता की जांच करने की अनुमति देती है।

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

इस प्रकार, यूनिट परीक्षण कीड़े के खिलाफ लड़ाई में पहला गढ़ है। इसके पीछे अभी भी एकीकरण, स्वीकृति और, "स्वतंत्र खोज" सहित मैनुअल परीक्षण है।

क्या आपको यह सब चाहिए? मेरे दृष्टिकोण से, उत्तर "हमेशा नहीं है।"

यदि परीक्षण लिखने की आवश्यकता नहीं है

आप 5 स्टैटिक html-पेजों का एक साधारण बिजनेस कार्ड साइट बनाते हैं और एक प्रकार के पत्र भेजते हैं। ग्राहक को इस पर शांत होने की संभावना है, उसे कुछ भी अधिक की आवश्यकता नहीं है। यहां कोई विशेष तर्क नहीं है, यह सब कुछ "अपने हाथों से" जांचने के लिए तेज़ है
आप एक विज्ञापन साइट / सरल फ़्लैश गेम्स या बैनर में लगे हुए हैं - जटिल लेआउट / एनीमेशन या स्थैतिक की एक बड़ी राशि। कोई तर्क नहीं है, केवल प्रतिनिधित्व है
आप प्रदर्शनी के लिए एक परियोजना कर रहे हैं। यह शब्द दो सप्ताह से एक महीने तक है, आपका सिस्टम हार्डवेयर और सॉफ्टवेयर का एक संयोजन है, परियोजना की शुरुआत में यह पूरी तरह से ज्ञात नहीं है कि अंत में क्या होना चाहिए। प्रदर्शनी में सॉफ्टवेयर 1-2 दिन काम करेगा
आप हमेशा त्रुटियों के बिना कोड लिखते हैं, सही स्मृति और दूरदर्शिता का उपहार है। क्लाइंट की आवश्यकताओं का पालन करते हुए आपका कोड इतना अच्छा होता है कि वह अपने आप बदल जाता है। कभी-कभी कोड क्लाइंट को समझाता है कि इसकी आवश्यकताएं - लागू करने की आवश्यकता नहीं है

उद्देश्य कारणों (तंग समय सीमा, बजट, धुंधले लक्ष्य या बहुत सरल आवश्यकताओं) के लिए पहले तीन मामलों में, आपको परीक्षण लिखने से कोई लाभ नहीं मिला।

हम बाद के मामले पर अलग से विचार करते हैं। मैं केवल एक ऐसे व्यक्ति को जानता हूं, और यदि आप नीचे दिए गए फोटो में खुद को नहीं पहचानते हैं, तो मेरे पास आपके लिए बुरी खबर है।

उचित परीक्षण कवरेज के बिना किसी भी दीर्घकालिक परियोजना को जल्द ही या बाद में खरोंच से फिर से लिखे जाने के लिए बर्बाद किया जाता है।

अपने अभ्यास में, मैं एक वर्ष से अधिक पुरानी परियोजनाओं के साथ कई बार मिला हूं। वे तीन श्रेणियों में आते हैं:

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

पहले प्रकार की परियोजनाएं एक कठिन अखरोट हैं, इसके साथ काम करना सबसे कठिन है। आमतौर पर, उनकी लागत रीफैक्टरिंग खरोंच से पुनर्लेखन के बराबर या उससे अधिक होती है।

दूसरे प्रकार की परियोजनाएँ क्यों हैं?

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

कोड के अंधेरे पक्ष के प्रबल न होने के लिए, आपको निम्नलिखित बुनियादी नियमों का पालन करना होगा।
आपके परीक्षण चाहिए:

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

इन बिंदुओं को प्राप्त करने के लिए, धैर्य और आवश्यकता होगी। लेकिन इसे क्रम में लेते हैं।

अपने VCS में तार्किक परीक्षण स्थान चुनें

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

परीक्षणों के साथ परियोजनाओं के नाम का रास्ता चुनें

सर्वोत्तम प्रथाओं में से एक: प्रत्येक परियोजना को अपने स्वयं के परीक्षण परियोजना में जोड़ें।
क्या आपके पास <PROJECT_NAME> .कोर, <PROJECT_NAME> .Bl और <PROECTECT_NAME> सिस्टम के कुछ भाग हैं? <PROJECT_NAME> .Core.Tests, <PROJECT_NAME> .Bl.Tests और <PROECTECT_NAME> .Web.Tests जोड़ें।

इस नामकरण विधि का एक अतिरिक्त दुष्प्रभाव है। बिल्ड सर्वर पर परीक्षण चलाने के लिए आप .Tests.dll पैटर्न का उपयोग कर सकते हैं।

परीक्षण कक्षाओं के लिए एक ही नामकरण विधि का उपयोग करें।

क्या आपके पास एक समस्या है। परीक्षण प्रोजेक्ट में ProblemResolverTests जोड़ें। प्रत्येक परीक्षण वर्ग को केवल एक इकाई का परीक्षण करना चाहिए। अन्यथा, आप बहुत तेज़ी ~~से एक सुस्त~~ परियोजना में दूसरे प्रकार की परियोजना में जाते हैं (परीक्षणों के साथ कि कोई भी नहीं चलता है)।

परीक्षण कक्षाओं के नामकरण विधियों के लिए एक "बात" विधि चुनें

TestLogin एक विधि का सबसे अच्छा नाम नहीं है। वास्तव में क्या परीक्षण किया जा रहा है? इनपुट पैरामीटर क्या हैं? क्या त्रुटियां और अपवाद हो सकते हैं?

मेरी राय में, तरीकों का नाम रखने का सबसे अच्छा तरीका है: [परीक्षण विधि] _ [स्क्रिप्ट] _ [अपेक्षित व्यवहार] ।
मान लें कि हमारे पास एक वर्ग कैलकुलेटर है, और इसमें एक विधि योग है, जो (हैलो, कैप!) दो संख्याओं को जोड़ना चाहिए।
इस मामले में, हमारा परीक्षण वर्ग इस तरह दिखेगा:

lass CalculatorTests { public void Sum_2Plus5_7Returned() { // … } }

बिना स्पष्टीकरण के ऐसा रिकॉर्ड समझ में आता है। यह आपके कोड के लिए विनिर्देशन है।

एक परीक्षण ढांचा चुनें जो आपको सूट करे

प्लेटफॉर्म के बावजूद, आपको साइकिल नहीं लिखना चाहिए। मैंने कई परियोजनाएं देखीं जिनमें स्वचालित परीक्षण (अधिकतर इकाइयां नहीं, बल्कि स्वीकृति परीक्षण) कंसोल एप्लिकेशन से चलाए गए थे। ऐसा करने की आवश्यकता नहीं है, सब कुछ आपके लिए पहले से ही किया गया है।

फ्रेमवर्क समीक्षा पर थोड़ा और ध्यान दें। उदाहरण के लिए, कई .NET डेवलपर्स MsTest का उपयोग केवल इसलिए करते हैं क्योंकि यह स्टूडियो में शामिल है। मुझे NUnit बहुत अधिक पसंद है। यह परीक्षण के परिणामों के साथ अतिरिक्त फ़ोल्डर नहीं बनाता है और इसे मानकीकृत परीक्षण के लिए समर्थन है। मैं बस आसानी से Resharper का उपयोग करके NUnit पर अपने परीक्षण चला सकता हूं। कोई xUnit के लालित्य को पसंद करेगा: प्रारंभिक विशेषताओं के बजाय एक निर्माणकर्ता, टियरडाउन के रूप में आईडीसिसोप्लीक को लागू करना।

क्या परीक्षण करें और क्या नहीं?

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

हम पहले चरम मामलों पर विचार करते हैं: निर्भरता के बिना एक सरल कोड और बड़ी संख्या में निर्भरता के साथ जटिल कोड।

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

हमारे साथ क्या रहता है:

निर्भरता के बिना जटिल कोड। ये कुछ एल्गोरिदम या व्यावसायिक तर्क हैं। खैर, ये सिस्टम के महत्वपूर्ण हिस्से हैं, हम उनका परीक्षण कर रहे हैं।
निर्भरता के साथ बहुत जटिल कोड नहीं। यह कोड विभिन्न घटकों को जोड़ता है। परीक्षण यह स्पष्ट करने के लिए महत्वपूर्ण है कि बातचीत कैसे होनी चाहिए। 23 सितंबर, 1999 को मार्स क्लाइमेट ऑर्बिटर के नुकसान का कारण एक मानव-सॉफ्टवेयर त्रुटि थी: परियोजना की एक इकाई को "इंच में," और दूसरे में "मीटर" में गिना गया था, और डिवाइस के नुकसान के बाद यह स्पष्ट किया गया था। परिणाम अलग हो सकता है अगर टीमों ने आवेदन के "तेजी" का परीक्षण किया।

परीक्षण के शरीर को लिखने की एक ही शैली के लिए छड़ी

एएए (व्यवस्था, कार्य, मुखर) दृष्टिकोण ने खुद को पूरी तरह से साबित कर दिया है । आइए कैलकुलेटर के साथ उदाहरण पर वापस जाएं:

 class CalculatorTests { public void Sum_2Plus5_7Returned() { // arrange var calc = new Calculator(); // act var res = calc.Sum(2,5); // assert Assert.AreEqual(7, res); } }

लिखने का यह रूप पढ़ने की तुलना में बहुत आसान है

 class CalculatorTests { public void Sum_2Plus5_7Returned() { Assert.AreEqual(7, new Calculator().sum(2,5)); } }

इसका मतलब है कि इस कोड को बनाए रखना आसान है।

एक समय में एक चीज का परीक्षण करें

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

नशे की लत से लड़ना

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

 public class AccountManagementController : BaseAdministrationController { #region Vars private readonly IOrderManager _orderManager; private readonly IAccountData _accountData; private readonly IUserManager _userManager; private readonly FilterParam _disabledAccountsFilter; #endregion public AccountManagementController() { _oms = OrderManagerFactory.GetOrderManager(); _accountData = _ orderManager.GetComponent<IAccountData>(); _userManager = UserManagerFactory.Get(); _disabledAccountsFilter = new FilterParam("Enabled", Expression.Eq, true); } }

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

 public class AccountManagementController : BaseAdministrationController { #region Vars private readonly IOrderManager _oms; private readonly IAccountData _accountData; private readonly IUserManager _userManager; private readonly FilterParam _disabledAccountsFilter; #endregion public AccountManagementController() { _oms = OrderManagerFactory.GetOrderManager(); _accountData = _oms.GetComponent<IAccountData>(); _userManager = UserManagerFactory.Get(); _disabledAccountsFilter = new FilterParam("Enabled", Expression.Eq, true); } /// <summary> /// For testability /// </summary> /// <param name="accountData"></param> /// <param name="userManager"></param> public AccountManagementController( IAccountData accountData, IUserManager userManager) { _accountData = accountData; _userManager = userManager; _disabledAccountsFilter = new FilterParam("Enabled", Expression.Eq, true); } }

अब नियंत्रक के पास एक नया प्रवेश बिंदु है, और हम वहां अन्य इंटरफ़ेस कार्यान्वयन कर सकते हैं।

नकली और स्टॉक्स

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

दो प्रकार के फेक हैं: स्टब्स (स्टब्स) और मोकी (मॉक)।
अक्सर ये अवधारणाएं भ्रमित होती हैं। अंतर यह है कि स्टब कुछ भी जांच नहीं करता है, लेकिन केवल एक दिए गए राज्य का अनुकरण करता है। मोख एक ऐसी वस्तु है जिसकी अपेक्षाएँ होती हैं। उदाहरण के लिए, किसी दिए गए वर्ग विधि को एक विशिष्ट संख्या कहा जाना चाहिए। दूसरे शब्दों में, "ठूंठ" के कारण आपका परीक्षण कभी नहीं टूटेगा, लेकिन मोका के कारण यह हो सकता है।
एक तकनीकी दृष्टिकोण से, इसका मतलब है कि एसेर में स्टब्स का उपयोग करके हम परीक्षण किए गए वर्ग की स्थिति या निष्पादित विधि का परिणाम जांचते हैं। मोका का उपयोग करते समय, हम जांचते हैं कि मोका की अपेक्षाएं परीक्षण किए गए वर्ग के व्यवहार के अनुरूप हैं या नहीं।

आवेश

 [Test] public void LogIn_ExisingUser_HashReturned() { // Arrange OrderProcessor = Mock.Of<IOrderProcessor>(); OrderData = Mock.Of<IOrderData>(); LayoutManager = Mock.Of<ILayoutManager>(); NewsProvider = Mock.Of<INewsProvider>(); Service = new IosService( UserManager, AccountData, OrderProcessor, OrderData, LayoutManager, NewsProvider); // Act var hash = Service.LogIn("ValidUser", "Password"); // Assert Assert.That(!string.IsNullOrEmpty(hash)); }

दिखावटी

 [Test] public void Create_AddAccountToSpecificUser_AccountCreatedAndAddedToUser() { // Arrange var account = Mock.Of<AccountViewModel>(); // Act _controller.Create(1, account); // Assert _accountData.Verify(m => m.CreateAccount(It.IsAny<IAccount>()), Times.Exactly(1)); _accountData.Verify(m => m.AddAccountToUser(It.IsAny<int>(), It.IsAny<int>()), Times.Once()); }

स्वास्थ्य परीक्षण और व्यवहार परीक्षण

मोक और स्टब्स के बीच प्रतीत होने वाले महत्वहीन अंतर को समझना क्यों महत्वपूर्ण है? आइए कल्पना करें कि हमें एक स्वचालित सिंचाई प्रणाली का परीक्षण करने की आवश्यकता है। इस कार्य को करने के दो तरीके हैं:

हालत परीक्षण

हम चक्र (12 घंटे) शुरू करते हैं। और 12 घंटे के बाद हम जांच करते हैं कि क्या पौधों को अच्छी तरह से पानी पिलाया गया है, क्या पर्याप्त पानी है, मिट्टी की स्थिति क्या है, आदि।

सहभागिता परीक्षण

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

इन्सुलेशन फ्रेमवर्क

हम अपने दम पर मोकी और स्टब्स लागू कर सकते हैं, लेकिन कई कारण हैं जो मैं ऐसा करने की सलाह नहीं देता:

हमसे पहले ही साइकिलें लिखी जा चुकी हैं
कई इंटरफेस आधे किक के साथ लागू करना इतना आसान नहीं है
हमारे स्व-निर्मित फेक में त्रुटियां हो सकती हैं
यह अतिरिक्त कोड है जिसका समर्थन करना होगा।

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

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

सूचीबद्ध अलगाव फ्रेमवर्क के शोकेस यहां देखे जा सकते हैं । और उनके साथ काम करने के तकनीकी पहलुओं की जानकारी हैबे पर खोजना आसान है।

परीक्षण के तहत वास्तुकला

आइए नियंत्रक उदाहरण पर वापस जाएं।

 public AccountManagementController( IAccountData accountData, IUserManager userManager) { _accountData = accountData; _userManager = userManager; _disabledAccountsFilter = new FilterParam("Enabled", Expression.Eq, true); }

यहाँ हम "थोड़ा खून" के साथ उतर गए। दुर्भाग्य से, सब कुछ हमेशा इतना सरल नहीं होता है। आइए मुख्य मामलों को देखें कि हम निर्भरता कैसे लागू कर सकते हैं:

कंस्ट्रक्टर इंजेक्शन

हम एक अतिरिक्त कंस्ट्रक्टर जोड़ते हैं या वर्तमान एक को बदलते हैं (यह इस बात पर निर्भर करता है कि आप अपने आवेदन में ऑब्जेक्ट कैसे बनाते हैं, चाहे आप आईओसी कंटेनर का उपयोग करें)। हमने ऊपर के उदाहरण में इस दृष्टिकोण का उपयोग किया है।

फैक्टरी इंजेक्शन

यदि आप IUserManagerFactory इंटरफ़ेस का चयन करते हैं और इंटरफ़ेस लिंक का उपयोग करके उत्पादन कोड में काम करते हैं तो सेटर मुख्य अनुप्रयोग से "छिपी" हो सकता है।

 public class UserManagerFactory { private IUserManager _instance; /// <summary> /// Get UserManager instance /// </summary> /// <returns>IUserManager with configuration from the configuration file</returns> public IUserManager Get() { return _instance ?? Get(UserConfigurationSection.GetSection()); } private IUserManager Get(UserConfigurationSection config) { return _instance ?? (_instance = Create(config)); } /// <summary> /// For testing purposes only! /// </summary> /// <param name="userManager"></param> public void Set(IUserManager userManager) { _instance = userManager; } }

फैक्ट्री स्पूफिंग

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

स्थानीय कारखाने विधि को ओवरराइड करें

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

 public class Calculator { public double Multipy(double a, double b) { var multiplier = new Multiplier(); return multiplier.Execute(a, b); } } public interface IArithmetic { double Execute(double a, double b); } public class Multiplier : IArithmetic { public double Execute(double a, double b) { return a * b; } }

हम गुणक वर्ग का परीक्षण नहीं करना चाहते हैं, इसके लिए एक अलग परीक्षण होगा। हम इस तरह कोड को फिर से लिखते हैं:

 public class Calculator { public double Multipy(double a, double b) { var multiplier = CreateMultiplier(); return multiplier.Execute(a, b); } protected virtual IArithmetic CreateMultiplier() { var multiplier = new Multiplier(); return multiplier; } } public class CalculatorUnderTest : Calculator { protected override IArithmetic CreateMultiplier() { return new FakeMultiplier(); } } public class FakeMultiplier : IArithmetic { public double Execute(double a, double b) { return 5; } }

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

वीएस ओओपी आर्किटेक्चर का परीक्षण किया गया

कई डेवलपर्स शिकायत करना शुरू करते हैं, "यह आपकी परीक्षण योग्य डिजाइन है", इनकैप्सुलेशन का उल्लंघन करता है, बहुत अधिक खोलता है। मुझे लगता है कि केवल दो कारण हैं जब यह आपको परेशान कर सकता है:

गंभीर सुरक्षा आवश्यकताएँ

इसका मतलब है कि आपके पास गंभीर क्रिप्टोग्राफी है, बायनेरिज़ पैक किए गए हैं, और सब कुछ प्रमाण पत्र के साथ लटका दिया गया है।
फिर भी, आपको एक समझौता मिलने की संभावना है। उदाहरण के लिए, .NET में, आप आंतरिक विधियों का उपयोग कर सकते हैं और [InternalsVanishTo] विशेषता का उपयोग कर अपने कंप्यूटर बिल्ड से परीक्षण विधियों तक पहुंच प्रदान कर सकते हैं।

उत्पादकता

ऐसे कई कार्य हैं जब प्रदर्शन के लिए वास्तुकला का बलिदान करना पड़ता है, और कुछ के लिए यह परीक्षण को मना करने का अवसर बन जाता है। मेरे व्यवहार में, सर्वर / अपग्रेडिंग हार्डवेयर को डॉक करना हमेशा अनस्टेबल कोड लिखने से सस्ता होता है। यदि आपके पास एक महत्वपूर्ण खंड है, तो संभवतः यह एक निचले स्तर पर इसे फिर से लिखने के लायक है। क्या आपका आवेदन C # में है? शायद यह C ++ में एक अप्रबंधित असेंबली बनाने के लिए समझ में आता है।

परीक्षण योग्य कोड लिखने में सहायता के लिए यहां कुछ दिशानिर्देश दिए गए हैं:

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

विरासत कोड के साथ काम करें

"विरासत" द्वारा हम परीक्षण के बिना कोड का मतलब है। ऐसे कोड की गुणवत्ता भिन्न हो सकती है। परीक्षणों के साथ इसे कैसे कवर किया जाए, इसके बारे में कुछ सुझाव।

वास्तुकला परीक्षण योग्य है

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

वास्तुकला परीक्षण योग्य नहीं है

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

समर्थन का परीक्षण करें

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

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

अपने परीक्षणों का समर्थन करने पर ध्यान दें, समय पर उनकी मरम्मत करें, डुप्लिकेट निकालें, बेस कक्षाओं को हाइलाइट करें और टेस्ट एपीआई विकसित करें। आप टेम्प्लेट बेस टेस्ट क्लासेस बना सकते हैं जो आपको परीक्षणों के एक सेट को लागू करने के लिए उपकृत करते हैं (उदाहरण के लिए, CRUD)। यदि आप नियमित रूप से ऐसा करते हैं, तो जल्द ही इसमें ज्यादा समय नहीं लगेगा।

प्रगति को कैसे मापें

अपनी परियोजना में इकाई परीक्षणों को लागू करने की सफलता को मापने के लिए, आपको दो मैट्रिक्स का उपयोग करना चाहिए:

नए रिलीज़ में बग्स की संख्या (प्रतिगमन सहित)
कोड कवरेज

पहले एक से पता चलता है कि क्या हमारे कार्यों का परिणाम है, या क्या हम समय बर्बाद कर रहे हैं जो हम सुविधाओं पर खर्च कर सकते हैं। दूसरा, कितना कुछ किया जाना बाकी है।

.NET प्लेटफ़ॉर्म पर कोड कवरेज को मापने के लिए सबसे लोकप्रिय उपकरण हैं:

Ncover
dotTrace
अंतर्निहित स्टूडियो टेस्ट कवरेज

पहले परीक्षण?

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

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

विषय पर पढ़ें

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

डमी के लिए यूनिट परीक्षण