युनिट चाचणीबद्दल सर्व: तंत्र, संकल्पना, सराव

आज तुम्हाला असा अनुप्रयोग सापडणार नाही जो चाचण्यांनी न भरलेला असेल, त्यामुळे हा विषय नवशिक्या विकसकांसाठी नेहमीपेक्षा अधिक संबंधित असेल: तुम्ही चाचण्यांशिवाय यशस्वी होऊ शकत नाही. तत्त्वतः कोणत्या प्रकारच्या चाचण्यांचा वापर केला जातो याचा विचार करूया, आणि नंतर युनिट चाचणीबद्दल जाणून घेण्यासाठी असलेल्या प्रत्येक गोष्टीचा तपशीलवार अभ्यास करू.

चाचणीचे प्रकार

चाचणी म्हणजे काय? विकिपीडियानुसार: "सॉफ्टवेअर चाचणीमध्ये स्वारस्याच्या एक किंवा अधिक गुणधर्मांचे मूल्यांकन करण्यासाठी सॉफ्टवेअर घटक किंवा सिस्टम घटकाची अंमलबजावणी समाविष्ट असते." दुसऱ्या शब्दांत, काही विशिष्ट परिस्थितींमध्ये आपल्या प्रणालीच्या शुद्धतेची तपासणी आहे. बरं, सर्वसाधारणपणे कोणत्या प्रकारच्या चाचण्या आहेत ते पाहू या:

• युनिट चाचणी — चाचण्या ज्यांचा उद्देश सिस्टमचे प्रत्येक मॉड्यूल स्वतंत्रपणे तपासणे आहे. या चाचण्या प्रणालीच्या सर्वात लहान अणू भागांवर लागू केल्या पाहिजेत, उदा. मॉड्यूल्स.
• सिस्टीम टेस्टिंग - अॅप्लिकेशनच्या मोठ्या भागाचे किंवा संपूर्ण सिस्टमचे ऑपरेशन तपासण्यासाठी उच्च-स्तरीय चाचणी.
• प्रतिगमन चाचणी — नवीन वैशिष्ट्ये किंवा बग निराकरणे अनुप्रयोगाच्या विद्यमान कार्यक्षमतेवर परिणाम करतात किंवा जुन्या बग्सचा परिचय करून देतात की नाही हे तपासण्यासाठी वापरली जाणारी चाचणी.
• कार्यात्मक चाचणी - अनुप्रयोगाचा एक भाग तपशील, वापरकर्ता कथा इत्यादींमध्ये नमूद केलेल्या आवश्यकता पूर्ण करतो की नाही हे तपासणे.

  कार्यात्मक चाचणीचे प्रकार:

  • व्हाईट-बॉक्स चाचणी — सिस्टमची अंतर्गत अंमलबजावणी जाणून घेत असताना अनुप्रयोगाचा एक भाग आवश्यकता पूर्ण करतो की नाही हे तपासणे;
  • ब्लॅक-बॉक्स चाचणी — सिस्टमची अंतर्गत अंमलबजावणी जाणून घेतल्याशिवाय अनुप्रयोगाचा एक भाग आवश्यकता पूर्ण करतो की नाही हे तपासणे.

• कार्यप्रदर्शन चाचणी - प्रणाली किंवा प्रणालीचा भाग एका विशिष्ट भाराखाली कसे कार्य करते हे निर्धारित करण्यासाठी लिहिलेल्या चाचण्या.
• लोड चाचणी — मानक लोड अंतर्गत सिस्टमची स्थिरता तपासण्यासाठी आणि अनुप्रयोग अद्याप योग्यरित्या कार्य करत असलेल्या कमाल लोड शोधण्यासाठी डिझाइन केलेल्या चाचण्या.
• स्ट्रेस टेस्टिंग - नॉन-स्टँडर्ड लोड अंतर्गत अॅप्लिकेशनची कार्यक्षमता तपासण्यासाठी आणि सिस्टम अयशस्वी होण्यापूर्वी जास्तीत जास्त लोड निश्चित करण्यासाठी डिझाइन केलेली चाचणी.
• सुरक्षा चाचणी — प्रणालीची सुरक्षितता तपासण्यासाठी वापरल्या जाणार्‍या चाचण्या (हॅकर्स, व्हायरस, गोपनीय डेटावर अनधिकृत प्रवेश आणि इतर आनंददायक हल्ल्यांपासून).
• स्थानिकीकरण चाचणी - अनुप्रयोगाच्या स्थानिकीकरणाच्या चाचण्या.
• उपयोगिता चाचणी - उपयोगिता, समजण्यायोग्यता, आकर्षकता आणि शिकण्याची क्षमता तपासण्याच्या उद्देशाने चाचणी.

हे सर्व चांगले वाटते, परंतु व्यवहारात ते कसे कार्य करते? सोपे! आम्ही माईक कोहनचा चाचणी पिरॅमिड वापरतो: ही पिरॅमिडची एक सरलीकृत आवृत्ती आहे: ती आता अगदी लहान भागांमध्ये विभागली गेली आहे. पण आज आपण खूप परिष्कृत होणार नाही. आम्ही सर्वात सोप्या आवृत्तीचा विचार करू.

1. युनिट — हा विभाग युनिट चाचण्यांचा संदर्भ देतो, ज्या अनुप्रयोगाच्या विविध स्तरांमध्ये लागू केल्या जातात. ते ऍप्लिकेशन लॉजिकच्या सर्वात लहान विभाज्य एककाची चाचणी करतात. उदाहरणार्थ, वर्ग, परंतु बहुतेकदा पद्धती. या चाचण्या सहसा कोणत्याही बाह्य तर्कशास्त्रातून तपासलेल्या गोष्टींना वेगळे करण्याचा शक्य तितका प्रयत्न करतात. म्हणजेच उर्वरित अर्ज अपेक्षेप्रमाणे चालत असल्याचा भ्रम निर्माण करण्याचा प्रयत्न करतात.

   या चाचण्या नेहमी भरपूर असाव्यात (इतर कोणत्याही प्रकारापेक्षा जास्त), कारण त्या लहान तुकड्यांचे परीक्षण करतात आणि खूप हलक्या असतात, भरपूर संसाधने वापरत नाहीत (म्हणजे RAM आणि वेळ).

2. एकत्रीकरण — हा विभाग एकीकरण चाचणीचा संदर्भ देतो. ही चाचणी प्रणालीचे मोठे तुकडे तपासते. म्हणजेच, ते एकतर तर्काचे अनेक तुकडे (अनेक पद्धती किंवा वर्ग) एकत्र करते किंवा ते बाह्य घटकासह परस्परसंवादाची शुद्धता तपासते. या चाचण्या सामान्यतः युनिट चाचण्यांपेक्षा लहान असतात कारण त्या वजनदार असतात.

   एकात्मिक चाचणीचे उदाहरण डेटाबेसशी कनेक्ट करणे आणि त्यासह कार्य करण्याच्या पद्धतींच्या ऑपरेशनची शुद्धता तपासणे असू शकते.

3. UI — हा विभाग वापरकर्ता इंटरफेसचे कार्य तपासणाऱ्या चाचण्यांचा संदर्भ देतो. ते ऍप्लिकेशनच्या सर्व स्तरांवर तर्कशास्त्राचा समावेश करतात, म्हणूनच त्यांना एंड-टू-एंड चाचण्या देखील म्हणतात. नियमानुसार, त्यापैकी खूपच कमी आहेत, कारण ते सर्वात अवजड आहेत आणि सर्वात आवश्यक (वापरलेले) मार्ग तपासले पाहिजेत.

   वरील चित्रात, आपण पाहतो की त्रिकोणाचे वेगवेगळे भाग आकारात भिन्न आहेत: वास्तविक कार्यात वेगवेगळ्या प्रकारच्या चाचण्यांच्या संख्येत अंदाजे समान प्रमाण अस्तित्वात आहे.

   आज आम्ही सर्वात सामान्य चाचण्या, युनिट चाचण्यांवर बारकाईने लक्ष देऊ, कारण सर्व स्वाभिमानी Java विकासक मूलभूत स्तरावर त्यांचा वापर करण्यास सक्षम असले पाहिजेत.

युनिट चाचणीमधील मुख्य संकल्पना

चाचणी कव्हरेज (कोड कव्हरेज) हे अनुप्रयोग किती चांगले तपासले जाते याचे मुख्य उपाय आहे. ही कोडची टक्केवारी आहे जी चाचण्यांद्वारे कव्हर केली जाते (0-100%). सराव मध्ये, बरेच लोक या टक्केवारीला त्यांचे ध्येय मानतात. या गोष्टीशी मी असहमत आहे, कारण चाचण्या आवश्यक नसलेल्या ठिकाणी लागू केल्या जाऊ लागतात. उदाहरणार्थ, समजा आमच्या सेवेमध्ये अतिरिक्त तर्काशिवाय मानक CRUD (तयार/मिळवा/अपडेट/हटवा) ऑपरेशन्स आहेत. या पद्धती पूर्णपणे मध्यस्थ आहेत जे रेपॉजिटरीसह काम करणार्‍या लेयरला काम सोपवतात. या परिस्थितीत, आमच्याकडे चाचणी करण्यासारखे काहीही नाही, कदाचित दिलेली पद्धत DAO पद्धत म्हणते की नाही, परंतु ती एक विनोद आहे. चाचणी कव्हरेजचे मूल्यांकन करण्यासाठी सामान्यतः अतिरिक्त साधने वापरली जातात: JaCoCo, Cobertura, Clover, Emma, ​​इ. या विषयाच्या अधिक तपशीलवार अभ्यासासाठी,

• कोड कव्हरेज मध्यम
• ब्लॅक बॉक्स चाचणी: उदाहरणे आणि तंत्रांसह सखोल ट्यूटोरियल

TDD म्हणजे चाचणी-चालित विकास. या दृष्टिकोनात, इतर काहीही करण्यापूर्वी, तुम्ही एक चाचणी लिहा जी विशिष्ट कोड तपासेल. हे ब्लॅक-बॉक्स चाचणी असल्याचे दिसून येते: आम्हाला इनपुट माहित आहे आणि आउटपुट काय असावे हे आम्हाला माहित आहे. हे कोड डुप्लिकेशन टाळणे शक्य करते. चाचणी-चालित विकास आपल्या ऍप्लिकेशनमधील कार्यक्षमतेच्या प्रत्येक बिटसाठी चाचण्या डिझाइन आणि विकसित करण्यापासून सुरू होतो. TDD दृष्टिकोनामध्ये, आम्ही प्रथम एक चाचणी तयार करतो जी कोडच्या वर्तनाची व्याख्या आणि चाचणी करते. तुमचा कोड अधिक समजण्याजोगा, सोपा आणि त्रुटीमुक्त करणे हे TDD चे मुख्य ध्येय आहे. दृष्टिकोनात खालील गोष्टींचा समावेश आहे:

• आम्ही आमची चाचणी लिहितो.
• आम्ही चाचणी चालवतो. आश्चर्याची गोष्ट म्हणजे, ते अयशस्वी होते, कारण आम्ही अद्याप आवश्यक तर्कशास्त्र लागू केलेले नाही.
• कोड जोडा ज्यामुळे चाचणी पास होते (आम्ही पुन्हा चाचणी चालवतो).
• आम्ही कोड रिफॅक्टर करतो.

TDD हे युनिट चाचण्यांवर आधारित आहे, कारण ते चाचणी ऑटोमेशन पिरॅमिडमधील सर्वात लहान बिल्डिंग ब्लॉक्स आहेत. युनिट चाचण्यांद्वारे, आम्ही कोणत्याही वर्गाच्या व्यावसायिक तर्काची चाचणी घेऊ शकतो. BDD म्हणजे वर्तन-चालित विकास. हा दृष्टिकोन TDD वर आधारित आहे. अधिक विशिष्‍टपणे, हे साध्या भाषेतील उदाहरणे वापरते जे विकासात सामील असलेल्या प्रत्येकासाठी प्रणालीचे वर्तन स्पष्ट करते. आम्ही या संज्ञेचा अभ्यास करणार नाही, कारण याचा प्रामुख्याने परीक्षक आणि व्यवसाय विश्लेषकांवर परिणाम होतो. चाचणी केस ही एक परिस्थिती आहे जी चाचणी अंतर्गत कोड तपासण्यासाठी आवश्यक असलेल्या पायऱ्या, विशिष्ट परिस्थिती आणि पॅरामीटर्सचे वर्णन करते. चाचणी फिक्स्चर हा कोड आहे जो चाचणी अंतर्गत पद्धत यशस्वीरित्या चालवण्यासाठी आवश्यक स्थितीसाठी चाचणी वातावरण सेट करते. हा वस्तूंचा पूर्वनिर्धारित संच आहे आणि विशिष्ट परिस्थितीत त्यांचे वर्तन आहे.

चाचणीचे टप्पे

चाचणीमध्ये तीन टप्पे असतात:

• चाचणी डेटा (फिक्स्चर) निर्दिष्ट करा.
• चाचणी अंतर्गत कोडचा व्यायाम करा (चाचणी केलेल्या पद्धतीवर कॉल करा).
• परिणामांची पडताळणी करा आणि अपेक्षित परिणामांशी तुलना करा.

चाचणी मॉड्यूलरिटी सुनिश्चित करण्यासाठी, आपल्याला अनुप्रयोगाच्या इतर स्तरांपासून वेगळे करणे आवश्यक आहे. हे स्टब्स, मॉक आणि हेर वापरून केले जाऊ शकते. मॉक अशा वस्तू आहेत ज्या सानुकूलित केल्या जाऊ शकतात (उदाहरणार्थ, प्रत्येक चाचणीसाठी तयार केलेले). ते आम्हाला मेथड कॉल्सकडून काय अपेक्षित आहे ते निर्दिष्ट करू देतात, म्हणजे अपेक्षित प्रतिसाद. आम्हाला जे अपेक्षित आहे ते आम्हाला मिळते याची पडताळणी करण्यासाठी आम्ही मॉक ऑब्जेक्ट्स वापरतो. स्टब्स चाचणी दरम्यान कॉलला हार्ड-कोडेड प्रतिसाद देतात. ते कॉलबद्दल माहिती देखील संग्रहित करू शकतात (उदाहरणार्थ, पॅरामीटर्स किंवा कॉलची संख्या). त्यांना कधीकधी हेर म्हणून संबोधले जाते. काहीवेळा लोक स्टब आणि मस्करी या संज्ञा गोंधळात टाकतात: फरक असा आहे की स्टब काहीही तपासत नाही - ते केवळ दिलेल्या स्थितीचे अनुकरण करते. उपहास म्हणजे अपेक्षा असलेली वस्तू. उदाहरणार्थ, दिलेल्या पद्धतीला ठराविक वेळा कॉल करणे आवश्यक आहे. दुसऱ्या शब्दात,

चाचणी वातावरण

तर, आता मुद्द्यावर. Java साठी अनेक चाचणी वातावरण (फ्रेमवर्क) उपलब्ध आहेत. यापैकी सर्वात लोकप्रिय JUnit आणि TestNG आहेत. येथे आमच्या पुनरावलोकनासाठी, आम्ही वापरतो: JUnit चाचणी ही वर्गातील एक पद्धत आहे जी केवळ चाचणीसाठी वापरली जाते. वर्गाला सामान्यतः ज्या वर्गाची चाचणी केली जाते त्याच नाव दिले जाते, शेवटी "चाचणी" जोडली जाते. उदाहरणार्थ, CarService -> CarServiceTest. मॅवेन बिल्ड सिस्टीम आपोआप अशा वर्गांचा चाचणी कार्यक्षेत्रात समावेश करते. खरे तर या वर्गाला चाचणी वर्ग म्हणतात. चला थोडक्यात मूलभूत भाष्ये पाहू:

• @Test सूचित करते की पद्धत एक चाचणी आहे (मुळात, या भाष्यासह चिन्हांकित केलेली पद्धत एक युनिट चाचणी आहे).
• @Before ही पद्धत सूचित करते जी प्रत्येक चाचणीपूर्वी कार्यान्वित केली जाईल. उदाहरणार्थ, चाचणी डेटासह वर्ग भरण्यासाठी, इनपुट डेटा वाचा इ.
• @After चा वापर प्रत्येक चाचणीनंतर कॉल केलेल्या पद्धतीला चिन्हांकित करण्यासाठी केला जातो (उदा. डेटा साफ करण्यासाठी किंवा डीफॉल्ट मूल्ये पुनर्संचयित करण्यासाठी).
• @BeforeClass एका पद्धतीच्या वर ठेवला आहे, @Before च्या समान आहे. परंतु अशा पद्धतीला दिलेल्या वर्गासाठी सर्व चाचण्यांपूर्वी फक्त एकदाच बोलावले जाते आणि म्हणून ते स्थिर असणे आवश्यक आहे. हे अधिक संसाधन-केंद्रित ऑपरेशन्स करण्यासाठी वापरले जाते, जसे की चाचणी डेटाबेस फिरवणे.
• @AfterClass हे @BeforeClass च्या विरुद्ध आहे: ते दिलेल्या वर्गासाठी एकदाच कार्यान्वित केले जाते, परंतु सर्व चाचण्यांनंतरच. हे वापरले जाते, उदाहरणार्थ, सतत संसाधने साफ करण्यासाठी किंवा डेटाबेसमधून डिस्कनेक्ट करण्यासाठी.
• @Ignore हे दर्शविते की एक पद्धत अक्षम केली आहे आणि एकूण चाचणी रन दरम्यान त्याकडे दुर्लक्ष केले जाईल. हे विविध परिस्थितींमध्ये वापरले जाते, उदाहरणार्थ, जर मूलभूत पद्धत बदलली गेली असेल आणि बदलांना सामावून घेण्यासाठी चाचणी अद्याप पुन्हा तयार केली गेली नसेल. अशा प्रकरणांमध्ये, वर्णन जोडणे देखील इष्ट आहे, म्हणजे @Ignore("काही वर्णन").
• @Test(expected = Exception.class) नकारात्मक चाचण्यांसाठी वापरला जातो. या अशा चाचण्या आहेत ज्या त्रुटीच्या बाबतीत पद्धत कशी वागते हे सत्यापित करतात, म्हणजेच, चाचणी पद्धतीला काही प्रकारचा अपवाद ठेवण्याची अपेक्षा आहे. अशी पद्धत @Test भाष्याद्वारे दर्शविली जाते, परंतु कोणती त्रुटी पकडायची याचे संकेत दिले आहे.
• @Test(टाइमआउट = 100) हे तपासते की पद्धत 100 मिलीसेकंदांपेक्षा जास्त नाही.
• @Mock फील्डच्या वर मॉक ऑब्जेक्ट नियुक्त करण्यासाठी वापरले जाते (हे JUnit भाष्य नाही, परंतु त्याऐवजी Mockito वरून येते). आवश्यकतेनुसार, आम्ही चाचणी पद्धतीमध्ये विशिष्ट परिस्थितीसाठी मॉकचे वर्तन सेट करतो.
• @RunWith(MockitoJUnitRunner.class) वर्गाच्या वर ठेवला आहे. हे भाष्य JUnit ला वर्गात चाचण्या घेण्यास सांगते. यासह विविध धावपटू आहेत: MockitoJUnitRunner, JUnitPlatform आणि SpringRunner. JUnit 5 मध्ये, @RunWith भाष्य अधिक शक्तिशाली @ExtendWith भाष्याने बदलले आहे.

परिणामांची तुलना करण्यासाठी वापरल्या जाणार्‍या काही पद्धती पाहू या:

• assertEquals(ऑब्जेक्ट अपेक्षित, ऑब्जेक्ट वास्तविक) — पास केलेले ऑब्जेक्ट्स समान आहेत की नाही हे तपासते.
• assertTrue(बूलियन ध्वज) — पास केलेले मूल्य खरे आहे की नाही ते तपासते.
• assertFalse(बूलियन ध्वज) — पास केलेले मूल्य असत्य आहे की नाही ते तपासते.
• assertNull(ऑब्जेक्ट ऑब्जेक्ट) - पास केलेला ऑब्जेक्ट शून्य आहे की नाही हे तपासते.
• assertSame(ऑब्जेक्ट फर्स्टऑब्जेक्ट, ऑब्जेक्ट सेकंडऑब्जेक्ट) — पास व्हॅल्यू समान ऑब्जेक्टचा संदर्भ घेते की नाही ते तपासते.
• assertThat(T t, matcher जुळणारा) — t matcher मध्ये निर्दिष्ट केलेली अट पूर्ण करते की नाही ते तपासते.

AssertJ एक उपयुक्त तुलना पद्धत देखील प्रदान करते: assertThat(firstObject).isEqualTo(secondObject) . येथे मी मूलभूत पद्धतींचा उल्लेख केला आहे - इतर वरील पद्धती आहेत.

सराव मध्ये चाचणी

आता वरील सामग्री एका विशिष्ट उदाहरणात पाहू. आम्ही सेवेच्या अपडेट पद्धतीची चाचणी करू. आम्ही DAO लेयरचा विचार करणार नाही, कारण आम्ही डीफॉल्ट वापरत आहोत. चाचण्यांसाठी स्टार्टर जोडूया:

<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-test</artifactId>
   <version>2.2.2.RELEASE</version>
   <scope>test</scope>
</dependency>

आणि येथे आमच्याकडे सेवा वर्ग आहे:

@Service
@RequiredArgsConstructor
public class RobotServiceImpl implements RobotService {
   private final RobotDAO robotDAO;

   @Override
   public Robot update(Long id, Robot robot) {
       Robot found = robotDAO.findById(id);
       return robotDAO.update(Robot.builder()
               .id(id)
               .name(robot.getName() != null ? robot.getName() : found.getName())
               .cpu(robot.getCpu() != null ? robot.getCpu() : found.getCpu())
               .producer(robot.getProducer() != null ? robot.getProducer() : found.getProducer())
               .build());
   }
}

ओळ 8 - डेटाबेसमधून अद्यतनित ऑब्जेक्ट खेचा. ओळी 9-14 — बिल्डरद्वारे एक ऑब्जेक्ट तयार करा. इनकमिंग ऑब्जेक्टमध्ये फील्ड असल्यास, ते सेट करा. नसल्यास, आम्ही डेटाबेसमध्ये काय आहे ते सोडू. आता आमची चाचणी पहा:

@RunWith(MockitoJUnitRunner.class)
public class RobotServiceImplTest {
   @Mock
   private RobotDAO robotDAO;

   private RobotServiceImpl robotService;

   private static Robot testRobot;

   @BeforeClass
   public static void prepareTestData() {
       testRobot = Robot
               .builder()
               .id(123L)
               .name("testRobotMolly")
               .cpu("Intel Core i7-9700K")
               .producer("China")
               .build();
   }

   @Before
   public void init() {
       robotService = new RobotServiceImpl(robotDAO);
   }

लाइन 1 - आमचा धावपटू. ओळ 4 - आम्ही DAO लेयरमधून एक मॉक बदलून सेवा विलग करतो. ओळ 11 — आम्ही वर्गासाठी एक चाचणी संस्था (ज्याला आम्ही गिनीपिग म्हणून वापरणार आहोत) सेट करतो. ओळ 22 - आम्ही सर्व्हिस ऑब्जेक्ट सेट करतो, ज्याची आम्ही चाचणी करू.

@Test
public void updateTest() {
   when(robotDAO.findById(any(Long.class))).thenReturn(testRobot);
   when(robotDAO.update(any(Robot.class))).then(returnsFirstArg());
   Robot robotForUpdate = Robot
           .builder()
           .name("Vally")
           .cpu("AMD Ryzen 7 2700X")
           .build();

   Robot resultRobot = robotService.update(123L, robotForUpdate);

   assertNotNull(resultRobot);
   assertSame(resultRobot.getId(),testRobot.getId());
   assertThat(resultRobot.getName()).isEqualTo(robotForUpdate.getName());
   assertTrue(resultRobot.getCpu().equals(robotForUpdate.getCpu()));
   assertEquals(resultRobot.getProducer(),testRobot.getProducer());
}

येथे आपण पाहतो की चाचणीमध्ये तीन स्पष्ट विभाग आहेत: रेषा 3-9 — फिक्स्चर निर्दिष्ट करणे. ओळ 11 - चाचणी अंतर्गत कोड कार्यान्वित करणे. ओळी 13-17 — परिणाम तपासत आहे. अधिक तपशीलात: ओळी 3-4 — DAO मॉकसाठी वर्तन सेट करा. ओळ 5 - आम्ही आमच्या मानकांच्या शीर्षस्थानी अद्यतनित करू असे उदाहरण सेट करा. ओळ 11 - पद्धत वापरा आणि परिणामी उदाहरण घ्या. ओळ 13 - ती शून्य नाही हे तपासा. ओळ 14 — निकालाच्या आयडीची आणि दिलेल्या पद्धतीच्या युक्तिवादांची तुलना करा. ओळ 15 - नाव अद्यतनित केले आहे की नाही ते तपासा. ओळ 16 — CPU परिणाम पहा. ओळ 17 - आम्ही हे फील्ड उदाहरणामध्ये निर्दिष्ट केले नाही, म्हणून ते समान राहिले पाहिजे. आम्ही ती स्थिती येथे तपासतो. चला ते चालवू:चाचणी हिरवी आहे! आम्ही सुटकेचा नि:श्वास सोडू शकतो :) सारांश, चाचणी कोडची गुणवत्ता सुधारते आणि विकास प्रक्रिया अधिक लवचिक आणि विश्वासार्ह बनवते. शेकडो क्लास फायलींचा समावेश असलेले सॉफ्टवेअर पुन्हा डिझाइन करण्यासाठी किती प्रयत्न करावे लागतील याची कल्पना करा. जेव्हा आमच्याकडे या सर्व वर्गांसाठी एकक चाचण्या लिहिल्या जातात, तेव्हा आम्ही आत्मविश्वासाने रिफॅक्टर करू शकतो. आणि सर्वात महत्त्वाचे म्हणजे, हे आम्हाला विकासादरम्यान सहजपणे बग शोधण्यात मदत करते. मित्रांनो आणि मुलींनो, आज माझ्याकडे एवढेच आहे. मला एक लाईक द्या आणि एक टिप्पणी द्या :)