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

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

एकीकरण परीक्षण - आप आसानी से एप्लिकेशन, लॉक कंपोनेंट्स, रिडिफाइन पैरामीटर आदि को लॉन्च कर सकते हैं।
फोकस एकीकरण परीक्षण - केवल डेटा तक पहुंच, केवल वेब, आदि।
बॉक्स से बाहर का समर्थन - इन-मेमोरी डेटाबेस, संदेश कतार, प्रमाणीकरण और परीक्षणों में प्राधिकरण
अनुबंधों के माध्यम से परीक्षण (स्प्रिंग क्लाउड अनुबंध)
HtmlUnit का उपयोग करके वेब UI परीक्षण समर्थन
आवेदन विन्यास की लचीलापन - प्रोफाइल, परीक्षण विन्यास, घटक, आदि।
और भी बहुत कुछ

टीडीडी और सामान्य रूप से परीक्षण के बारे में एक छोटा लेकिन आवश्यक परिचय।

परीक्षण संचालित विकास

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

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

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

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

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

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

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

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

लेखों की एक श्रृंखला के लिए एक नमूना योजना, जैसा कि मैं इसे फिलहाल देखता हूं, वह है:

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

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

उपयोगकर्ता कहानी एक प्राकृतिक भाषा अनुप्रयोग की एक विशेषता का विवरण है जो आमतौर पर सिस्टम के उपयोगकर्ता की ओर से लिखा जाता है।

उपयोगकर्ता कहानी 1: उपयोगकर्ता स्वागत पृष्ठ देखता है

ऐलिस के रूप में , एक नया उपयोगकर्ता
केक फैक्ट्री की वेब-साइट पर जाकर मैं एक स्वागत योग्य पृष्ठ देखना चाहता हूं
ताकि मुझे पता चले कि कब केक फैक्ट्री लॉन्च होने वाली है

स्वीकृति मानदंड:
परिदृश्य: लॉन्च की तारीख से पहले वेब-साइट पर जाने वाला उपयोगकर्ता
यह देखते हुए कि मैं एक नया उपयोगकर्ता हूं
जब मैं केक फैक्टरी वेब-साइट पर जाता हूं
तब मुझे एक संदेश दिखाई देता है 'आपकी रुचि के लिए धन्यवाद'
और मुझे एक संदेश दिखाई दे रहा है 'वेब-साइट जल्द ही आ रही है ...'

यह ज्ञान लेगा: व्यवहार-विकास और ककड़ी क्या है, स्प्रिंग बूट परीक्षण की मूल बातें।

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

वेब और मूंछ मॉड्यूल के साथ स्प्रिंग प्रिन्टिज़र पर एक नई परियोजना बनाने के बाद, एक शुरुआत के लिए मुझे निर्माण build.gradle लिए कुछ और बदलावों की आवश्यकता होगी:

HtmlUnit testImplementation('net.sourceforge.htmlunit:htmlunit') । आपको संस्करण निर्दिष्ट करने की आवश्यकता नहीं है, ग्रैडल के लिए स्प्रिंग बूट निर्भरता प्रबंधन प्लगइन स्वचालित रूप से आवश्यक और संगत संस्करण का चयन करेगा
किसी परियोजना को JUnit 4 से JUnit 5 पर ले जाएं (क्योंकि 2018 यार्ड में है)
ककड़ी के लिए निर्भरता जोड़ें - एक पुस्तकालय जिसे मैं बीडीडी विनिर्देशों को लिखने के लिए उपयोग करूंगा
डिफ़ॉल्ट CakeFactoryApplicationTests द्वारा बनाया गया है अपरिहार्य contextLoads साथ बनाया हटा दें

द्वारा और बड़े, यह आवेदन का मूल "कंकाल" है, आप पहले से ही पहला परीक्षण लिख सकते हैं।

कोड में नेविगेट करना आसान बनाने के लिए, मैं संक्षेप में प्रयुक्त तकनीकों के बारे में बात करूंगा।

ककड़ी

ककड़ी एक व्यवहार-प्रेरित विकास ढांचा है जो "निष्पादन योग्य विनिर्देशों" को बनाने में मदद करता है, अर्थात। प्राकृतिक भाषा में लिखित परीक्षण (विनिर्देशन) चलाएं। ककड़ी प्लगइन जावा (और कई अन्य भाषाओं) में स्रोत कोड को पार्स करता है और वास्तविक कोड को चलाने के लिए चरण परिभाषाओं का उपयोग करता है। चरण परिभाषाएँ वर्ग विधियाँ हैं जो @Given , @When , @Then और अन्य एनोटेशन द्वारा एनोटेट की जाती हैं।

HtmlUnit

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

पहले परीक्षण

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

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

तो, मेरी पहली विशेषता।

 Feature: Welcome page Scenario: a user visiting the web-site visit before the launch date Given a new user, Alice When she visits Cake Factory web-site Then she sees a message 'Thank you for your interest' And she sees a message 'The web-site is coming in December!'

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

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

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

लाल

इसलिए, अपनी पहली विशेषता के लिए, मैंने निम्नलिखित चरण विवरण तैयार किए:

 @SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT) public class WelcomePage { private WebClient webClient; private HtmlPage page; @LocalServerPort private int port; private String baseUrl; @Before public void setUp() { webClient = new WebClient(); baseUrl = "http://localhost:" + port; } @Given("a new user, Alice") public void aNewUser() { // nothing here, every user is new by default } @When("she visits Cake Factory web-site") public void sheVisitsCakeFactoryWebSite() throws IOException { page = webClient.getPage(baseUrl); } @Then("she sees a message {string}") public void sheSeesAMessageThanksForYourInterest(String expectedMessage) { assertThat(page.getBody().asText()).contains(expectedMessage); } }

कुछ बिंदुओं पर ध्यान देना:

फीचर्स एक अन्य फ़ाइल द्वारा लॉन्च किए गए हैं, Features.java JUnit 4 से RunWith एनोटेशन का उपयोग करते हुए, ककड़ी संस्करण 5, RunWith का समर्थन नहीं करता है
@SpringBootTest एनोटेशन चरणों के विवरण में जोड़ा जाता है, cucumber-spring इसे वहां से उठाता है और परीक्षण संदर्भ को कॉन्फ़िगर करता है (यानी, एप्लिकेशन लॉन्च करता है)
परीक्षण के लिए स्प्रिंग अनुप्रयोग webEnvironment = RANDOM_PORT शुरू होता है और यह यादृच्छिक पोर्ट @LocalServerPort का उपयोग करके परीक्षण में पास किया @LocalServerPort , स्प्रिंग को यह एनोटेशन मिलेगा और सर्वर पोर्ट पर फ़ील्ड मान सेट करेगा

और परीक्षण, जैसा कि अपेक्षित था, 404 for http://localhost:51517 त्रुटि 404 for http://localhost:51517 साथ क्रैश।

जिन त्रुटियों के साथ परीक्षण क्रैश होता है वे अविश्वसनीय रूप से महत्वपूर्ण होते हैं, खासकर जब यूनिट या एकीकरण परीक्षणों की बात आती है, और ये त्रुटियां एपीआई का हिस्सा होती हैं। यदि परीक्षण NullPointerException साथ क्रैश हो जाता है NullPointerException यह बहुत अच्छा नहीं है, लेकिन BaseUrl configuration property is not set - बहुत बेहतर।

ग्रीन

परीक्षण को हरा बनाने के लिए, मैंने न्यूनतम HTML के साथ एक आधार नियंत्रक और दृश्य जोड़ा:

 @Controller public class IndexController { @GetMapping public String index() { return "index"; } }

 <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>Cake Factory</title> </head> <body> <h1>Thank you for your interest</h1> <h2>The web-site is coming in December!</h2> </body> </html>

परीक्षण हरा है, आवेदन काम करता है, हालांकि यह गंभीर इंजीनियरिंग डिजाइन की परंपरा में बनाया गया है।

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

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

Refactor

पहले पुनरावृत्ति में, कोई विशेष रीफ़ैक्टरिंग नहीं है, लेकिन हालांकि, मैंने पिछले 10 मिनट बुलमा के लिए एक टेम्पलेट चुनने में बिताए, जिसे रिफैक्टरिंग के रूप में गिना जा सकता है!

निष्कर्ष में

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

संदर्भ

गिटहब परियोजना
समागम सी.आई.

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

स्प्रिंग बूट पर ट्रंक या टेस्ट-प्रेरित विकास अनुप्रयोगों में एक पिरामिड का निर्माण कैसे करें