अंत में परीक्षण लिखना कैसे शुरू करें और इसे पछतावा न करें

एक नई परियोजना के लिए, मैं नियमित रूप से निम्नलिखित स्थितियों में से एक में आता हूं:

1. कोई परीक्षण नहीं हैं।
2. कुछ परीक्षण हैं, वे शायद ही कभी लिखे गए हैं और निरंतर आधार पर नहीं चलते हैं।
3. टेस्ट मौजूद हैं और सीआई (कंटीन्यूअस इंटीग्रेशन) में शामिल हैं, लेकिन अच्छे से ज्यादा नुकसान पहुंचाते हैं।

दुर्भाग्य से, यह बाद का परिदृश्य है जो अक्सर उपयुक्त कौशल की अनुपस्थिति में परीक्षण को लागू करने के लिए गंभीर प्रयासों की ओर जाता है।

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


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

चूंकि मेरा मुख्य विशेषज्ञता जावा बैकेंड है, इसलिए निम्न प्रौद्योगिकी स्टैक का उपयोग उदाहरणों में किया जाएगा: जावा, जुनिट, एच 2, मॉकिटो, स्प्रिंग, हाइबरनेट। इसी समय, लेख का एक महत्वपूर्ण हिस्सा सामान्य परीक्षण के मुद्दों के लिए समर्पित है और इसमें युक्तियां बहुत व्यापक कार्यों के लिए लागू हैं।

हालाँकि, सावधान रहें! परीक्षण बहुत व्यसनी हैं: एक बार जब आप सीखते हैं कि उनका उपयोग कैसे करना है, तो आप अब उनके बिना नहीं रह सकते।

टेस्ट बनाम विकास की गति

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

लेकिन हम किस तरह की दक्षता की बात कर रहे हैं? आइए कार्यान्वयन की कठिनाइयों के बारे में गीतों को छोड़ दें और देखें कि समय परीक्षण को बचाने के लिए क्या विशिष्ट अवसर खुलते हैं।

किसी भी स्थान पर चल रहा कोड

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

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

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

पुनरावर्ती टेस्ट

इस प्लस को अक्सर टेस्ट ऑटोमेशन के सार के रूप में उद्धृत किया जाता है, लेकिन इसे कम परिचित कोण से देखें। यह डेवलपर्स के लिए क्या नए अवसर खोलता है?

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

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

डिबगिंग

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

प्रभावशीलता

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

सिद्धांत से अभ्यास तक

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

कार्य

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

डोमेन मॉडल

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



ग्राहक के पास एक उपयोगकर्ता नाम, एक पसंदीदा उत्पाद का लिंक और एक ध्वज होता है जो दर्शाता है कि वह एक प्रीमियम ग्राहक है।

उत्पाद (उत्पाद) - नाम, मूल्य, छूट और ध्वज यह दर्शाता है कि क्या यह वर्तमान में विज्ञापित है।

परियोजना की संरचना

मुख्य परियोजना कोड की संरचना इस प्रकार है।



वर्ग स्तरित हैं:

• मॉडल - परियोजना का डोमेन मॉडल;
• जेपीए - स्प्रिंग डेटा पर आधारित डेटाबेस के साथ काम करने के लिए रिपॉजिटरी;
• सेवा - आवेदन का व्यावसायिक तर्क;
• नियंत्रक - एपीआई को लागू करने वाले नियंत्रक।

इकाई परीक्षण संरचना।



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

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



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

एकीकरण परीक्षण

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

आर्किटेक्चर

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

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

 @PostMapping("new") public Product createProduct(@RequestBody Product product) { return productService.createProduct(product); } @GetMapping("{productId}") public Product getProduct(@PathVariable("productId") long productId) { return productService.getProduct(productId); } @PostMapping("{productId}/edit") public void updateProduct(@PathVariable("productId") long productId, @RequestBody Product product) { productService.updateProduct(productId, product); } 

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

 @Transactional(readOnly = true) public Product getProduct(Long productId) { return productRepository.findById(productId) .orElseThrow(() -> new DataNotFoundException("Product", productId)); } @Transactional public Product createProduct(Product product) { return productRepository.save(new Product(product)); } @Transactional public Product updateProduct(Long productId, Product product) { Product dbProduct = productRepository.findById(productId) .orElseThrow(() -> new DataNotFoundException("Product", productId)); dbProduct.setPrice(product.getPrice()); dbProduct.setDiscount(product.getDiscount()); dbProduct.setName(product.getName()); dbProduct.setIsAdvertised(product.isAdvertised()); return productRepository.save(dbProduct); } 

ProductRepository रिपॉजिटरी में अपने तरीके बिल्कुल नहीं होते हैं:

 public interface ProductRepository extends JpaRepository<Product, Long> { } 

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

विन्यास

सुविधा के लिए, हम बेस क्लास BaseControllerIT उजागर करते हैं, जिसमें स्प्रिंग कॉन्फ़िगरेशन और कुछ फ़ील्ड शामिल हैं:

 @RunWith(SpringRunner.class) @SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.NONE) @Transactional public abstract class BaseControllerIT { @Autowired protected ProductRepository productRepository; @Autowired protected CustomerRepository customerRepository; } 

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

वसंत का मुख्य विन्यास निम्नलिखित पंक्तियों द्वारा परिभाषित किया गया है:

@SpringBootTest - एप्लिकेशन का संदर्भ सेट करने के लिए उपयोग किया जाता है। WebEnvironment.NONE मतलब है कि किसी वेब संदर्भ को WebEnvironment.NONE आवश्यकता नहीं है।

@Transactional - डेटाबेस की स्थिति को बचाने के लिए स्वचालित रोलबैक के साथ लेनदेन में सभी वर्ग परीक्षणों को लपेटता है।

परीक्षण संरचना

चलो ProductController वर्ग - ProductControllerIT लिए परीक्षणों के एक न्यूनतम सेट पर चलते हैं।

 @Test public void createProduct_productSaved() { Product product = product("productName").price("1.01").discount("0.1").advertised(true).build(); Product createdProduct = productController.createProduct(product); Product dbProduct = productRepository.getOne(createdProduct.getId()); assertEquals("productName", dbProduct.getName()); assertEquals(number("1.01"), dbProduct.getPrice()); assertEquals(number("0.1"), dbProduct.getDiscount()); assertEquals(true, dbProduct.isAdvertised()); } 

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

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

 assertEquals(product, dbProduct); 

उत्पाद जानकारी ( updateProduct ) को अपडेट करने के लिए एक अन्य परीक्षण में, यह स्पष्ट है कि डेटा का निर्माण थोड़ा अधिक जटिल हो गया है और परीक्षण के तीन हिस्सों की दृश्य अखंडता को बनाए रखने के लिए, उन्हें एक पंक्ति में दो पंक्ति फीड द्वारा अलग किया जाता है:

 @Test public void updateProduct_productUpdated() { Product product = product("productName").build(); productRepository.save(product); Product updatedProduct = product("updatedName").price("1.1").discount("0.5").advertised(true).build(); updatedProduct.setId(product.getId()); productController.updateProduct(product.getId(), updatedProduct); Product dbProduct = productRepository.getOne(product.getId()); assertEquals("updatedName", dbProduct.getName()); assertEquals(number("1.1"), dbProduct.getPrice()); assertEquals(number("0.5"), dbProduct.getDiscount()); assertEquals(true, dbProduct.isAdvertised()); } 

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

टेस्ट बिल्डरों

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

 public static ProductBuilder product(String name) { return new ProductBuilder() .name(name) .advertised(false) .price("0.00"); } 

टेस्ट नाम

यह समझना जरूरी है कि इस परीक्षण में क्या विशेष रूप से परीक्षण किया गया है। स्पष्टता के लिए, इस सवाल का जवाब अपने शीर्षक में देना सबसे अच्छा है। getProduct विधि के लिए नमूना परीक्षणों का उपयोग करना, उपयोग किए गए नामकरण सम्मेलन पर विचार करें:

 @Test public void getProduct_oneProductInDb_productReturned() { Product product = product("productName").build(); productRepository.save(product); Product result = productController.getProduct(product.getId()); assertEquals("productName", result.getName()); } @Test public void getProduct_twoProductsInDb_correctProductReturned() { Product product1 = product("product1").build(); Product product2 = product("product2").build(); productRepository.save(product1); productRepository.save(product2); Product result = productController.getProduct(product1.getId()); assertEquals("product1", result.getName()); } 

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



निष्कर्ष

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

यह ध्यान देने योग्य है कि इस तरह के परीक्षण आवेदन की वेब परत की जांच नहीं करते हैं, लेकिन अक्सर यह आवश्यक नहीं है। यदि आवश्यक हो, तो आप आधार ( @WebMvcTest , MockMvc , @MockBean ) के बजाय एक स्टब के साथ वेब परत के लिए अलग-अलग परीक्षण लिख सकते हैं या एक पूर्ण सर्वर का उपयोग कर सकते हैं। उत्तरार्द्ध डिबगिंग को जटिल कर सकता है और लेनदेन के साथ काम को जटिल कर सकता है, क्योंकि परीक्षण सर्वर के लेनदेन को नियंत्रित नहीं कर सकता है। इस तरह के एकीकरण परीक्षण का एक उदाहरण CustomerControllerServerIT वर्ग में पाया जा सकता है।

यूनिट परीक्षण

एकीकरण परीक्षणों पर यूनिट परीक्षणों के कई फायदे हैं:

• स्टार्टअप मिलिसेकंड लेता है;
• परीक्षण की गई इकाई का छोटा आकार;
• बड़ी संख्या में विकल्पों के सत्यापन को लागू करना आसान है, क्योंकि जब विधि को सीधे कहा जाता है, तो डेटा तैयारी बहुत सरल होती है।

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

इस उदाहरण में एकमात्र वर्ग जो यूनिट परीक्षण के योग्य है, वह है BonusPointCalculator । इसकी विशिष्ट विशेषता व्यावसायिक तर्क की एक बड़ी संख्या है। उदाहरण के लिए, यह माना जाता है कि खरीदार को उत्पाद की लागत का 10% का बोनस प्राप्त होता है, जो निम्न सूची से 2 गुणक से कई गुना अधिक है:

• उत्पाद की लागत 10,000 (× 4) से अधिक है;
• उत्पाद एक विज्ञापन अभियान (× 3) में भाग लेता है;
• उत्पाद ग्राहक का "पसंदीदा" उत्पाद है (× 5);
• ग्राहक के पास एक प्रीमियम स्थिति (× 2) है;
• यदि ग्राहक के पास प्रीमियम स्थिति है और "पसंदीदा" उत्पाद खरीदता है, तो दो संकेतित गुणक के बजाय, एक (× 8) का उपयोग किया जाता है।

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

 private List<BigDecimal> calculateMultipliers(Customer customer, Product product) { List<BigDecimal> multipliers = new ArrayList<>(); if (customer.getFavProduct() != null && customer.getFavProduct().equals(product)) { if (customer.isPremium()) { multipliers.add(PREMIUM_FAVORITE_MULTIPLIER); } else { multipliers.add(FAVORITE_MULTIPLIER); } } else if (customer.isPremium()) { multipliers.add(PREMIUM_MULTIPLIER); } if (product.isAdvertised()) { multipliers.add(ADVERTISED_MULTIPLIER); } if (product.getPrice().compareTo(EXPENSIVE_THRESHOLD) >= 0) { multipliers.add(EXPENSIVE_MULTIPLIER); } return multipliers; } 

बड़ी संख्या में विकल्प इस तथ्य की ओर ले जाते हैं कि दो या तीन एकीकरण परीक्षण यहां सीमित नहीं हैं। ऐसी कार्यक्षमता को डीबग करने के लिए इकाई परीक्षणों का एक न्यूनतम सेट सही है।



इसी परीक्षण सूट को BonusPointCalculatorTest क्लास में पाया जा सकता है। यहाँ उनमें से कुछ हैं:

 @Test public void calculate_oneProduct() { Product product = product("product").price("1.00").build(); Customer customer = customer("customer").build(); Map<Product, Long> quantities = mapOf(product, 1L); BigDecimal bonus = bonusPointCalculator.calculate(customer, list(product), quantities::get); BigDecimal expectedBonus = bonusPoints("0.10").build(); assertEquals(expectedBonus, bonus); } @Test public void calculate_favProduct() { Product product = product("product").price("1.00").build(); Customer customer = customer("customer").favProduct(product).build(); Map<Product, Long> quantities = mapOf(product, 1L); BigDecimal bonus = bonusPointCalculator.calculate(customer, list(product), quantities::get); BigDecimal expectedBonus = bonusPoints("0.10").addMultiplier(FAVORITE_MULTIPLIER).build(); assertEquals(expectedBonus, bonus); } 

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

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

 @Test public void calculateBonusPoints_twoProductTypes_correctValueCalculated() { Product product1 = product("product1").price("1.01").build(); Product product2 = product("product2").price("10.00").build(); productRepository.save(product1); productRepository.save(product2); Customer customer = customer("customer").build(); customerRepository.save(customer); Map<Long, Long> quantities = mapOf(product1.getId(), 1L, product2.getId(), 2L); BigDecimal bonus = customerController.calculateBonusPoints( new CalculateBonusPointsRequest("customer", quantities) ); BigDecimal bonusPointsProduct1 = bonusPoints("0.10").build(); BigDecimal bonusPointsProduct2 = bonusPoints("1.00").quantity(2).build(); BigDecimal expectedBonus = bonusPointsProduct1.add(bonusPointsProduct2); assertEquals(expectedBonus, bonus); } 

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

कार्यान्वयन सिफारिशें

मुझे उम्मीद है कि पिछले अनुभाग कम से कम एक डेवलपर को अपनी परियोजना में परीक्षणों का उपयोग शुरू करने के लिए मनाने के लिए पर्याप्त थे। यह अध्याय मुख्य सिफारिशों को संक्षेप में सूचीबद्ध करेगा जो गंभीर समस्याओं से बचने और कम प्रारंभिक कार्यान्वयन लागतों का नेतृत्व करने में मदद करेगा।

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

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

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

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

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

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

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

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

, . , - . , . , , — , .

. , , . , , .

TDD (Test-Driven Development). TDD , , . , , . , , .

, ?

, :

1. ( )? .
2. , ( , CI)? .
3. ? .
4. ? . , , .

, . , , - . — .

निष्कर्ष

, . - , . , - . — , , -. , .

, , , !

GitHub