क्या आपकी कभी यह हालत हुई है?

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

नीचे मैं दिखाऊंगा कि सबसे बड़े अंतर कहां थे।

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

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

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

फिर से टीडीडी क्या है

टीडीडी - परीक्षण के माध्यम से विकास। विकी लेख यहाँ ।
क्लासिक दृष्टिकोण पहले एक आवेदन लिखना है, फिर इसे परीक्षणों के साथ कवर करें।

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

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

व्यावहारिक कार्य

मान लीजिए कि हम इतने भाग्यशाली हैं कि हमारे पास विकसित करने के लिए आवश्यक TOR है। आमतौर पर, विश्लेषक इससे परेशान नहीं होते हैं, और यह कुछ इस तरह दिखता है:

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

व्यवसाय तर्क निम्नानुसार है: यदि कोई वस्तु बिक्री के लिए उपलब्ध है तो:

उत्पाद स्टॉक में है
ठेकेदार (उदाहरण के लिए, कंपनी DostavchenKO) के पास इसे ग्राहक तक ले जाने का अवसर है
उत्पाद का रंग - नीला नहीं (हमें नीला पसंद नहीं है)

हमारे माइक्रोसॉर्फ़ को http-request के माध्यम से स्टोर शेल्फ पर माल की मात्रा में बदलाव के बारे में सूचित किया जाएगा।

यह सूचना उपलब्धता की गणना के लिए एक ट्रिगर है।

प्लस, ताकि जीवन शहद नहीं लगता है:

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

हम टीके के कुछ समय पढ़ते हैं - और जाते हैं।

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

टीडीडी में, सबसे महत्वपूर्ण प्रश्नों में से एक जो आपको लिखना है वह सब कुछ है: "मुझे क्या चाहिए ...?"

और पहला सवाल जो हम पूछते हैं वह सिर्फ पूरे आवेदन के लिए है।
तो सवाल यह है:

मैं अपने माइक्रो सर्विस से क्या चाहता हूं?

उत्तर है:

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

यही है, हम मानते हैं कि सभी इनपुट डेटा वैध प्रारूप हैं, तीसरे पक्ष के सिस्टम सामान्य रूप से प्रतिक्रिया करते हैं, और पहले उत्पाद पर कोई जानकारी नहीं थी।

तो, मैं चाहता हूं:

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

यहां मुख्य चीज समय में रुकना है: जैसा कि मैंने पहले ही लिखा है, बहुत सारे विकल्प हैं, और यह उन सभी का वर्णन करने के लिए कोई मतलब नहीं है - केवल सबसे बुनियादी। भविष्य में, जब हम व्यावसायिक तर्क के लिए परीक्षण लिखते हैं, तो उनके संयोजन में उन सभी चीजों को शामिल करने की संभावना होती है जो हम यहां लाते हैं। यहां मुख्य प्रेरणा यह सुनिश्चित करना है कि यदि ये परीक्षण पास हो जाते हैं, तो आवेदन हमारी आवश्यकतानुसार काम करता है।

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

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

@Test public void notifyNotAvailableIfProductQuantityIsZero() {} @Test public void notifyAvailableYellowProductIfPositiveQuantityAndDostavchenkoApproved() {} @Test public void notifyOnceOnSeveralEqualProductMessages() {} @Test public void notifyFirstAvailableThenNotIfProductQuantityMovedFromPositiveToZero() {} @Test public void noNotificationOnDisabledProduct() {}

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

परीक्षण भरना शुरू करें

मुख्य विचार यह है कि अंदर क्या हो रहा है यह जांचने के लिए सब कुछ बाहरी अनुकरण करना है।

हमारी सेवा के संबंध में "बाहरी" वह सब है जो स्वयं माइक्रोसेवर नहीं है, लेकिन यह सीधे इसके साथ संचार करता है।

इस मामले में, बाहरी है:

वह प्रणाली जो हमारी सेवा माल की मात्रा में परिवर्तन के बारे में सूचित करेगी
ग्राहक जो सामान को मैन्युअल रूप से काट देगा
तृतीय-पक्ष DostavchenKO प्रणाली

पहले दो के अनुरोधों का अनुकरण करने के लिए, हम स्प्रिंगिंग MockMvc का उपयोग करते हैं।
DostavchenKO का अनुकरण करने के लिए हम वायरमॉक या MockRestServiceServer का उपयोग करते हैं।

परिणामस्वरूप, हमारा एकीकरण परीक्षण इस तरह दिखता है:

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

 @RunWith(SpringRunner.class) @SpringBootTest @AutoConfigureMockMvc @AutoConfigureWireMock(port = 8090) public class TddExampleApplicationTests { @Autowired private MockMvc mockMvc; @Before public void init() { WireMock.reset(); } @Test public void notifyNotAvailableIfProductQuantityIsZero() throws Exception { stubNotification( // language=JSON "{\n" + " \"productId\": 111,\n" + " \"available\": false\n" + "}"); performQuantityUpdateRequest( // language=JSON "{\n" + " \"productId\": 111,\n" + " \"color\" : \"red\", \n" + " \"productQuantity\": 0\n" + "}"); verify(1, postRequestedFor(urlEqualTo("/notify"))); } @Test public void notifyAvailableYellowProductIfPositiveQuantityAndDostavchenkoApproved() throws Exception { stubDostavchenko("112"); stubNotification( // language=JSON "{\n" + " \"productId\": 112,\n" + " \"available\": true\n" + "}"); performQuantityUpdateRequest( // language=JSON "{\n" + " \"productId\": 112,\n" + " \"color\" : \"Yellow\", \n" + " \"productQuantity\": 10\n" + "}"); verify(1, postRequestedFor(urlEqualTo("/notify"))); } @Test public void notifyOnceOnSeveralEqualProductMessages() throws Exception { stubDostavchenko("113"); stubNotification( // language=JSON "{\n" + " \"productId\": 113,\n" + " \"available\": true\n" + "}"); for (int i = 0; i < 5; i++) { performQuantityUpdateRequest( // language=JSON "{\n" + " \"productId\": 113,\n" + " \"color\" : \"Yellow\", \n" + " \"productQuantity\": 10\n" + "}"); } verify(1, postRequestedFor(urlEqualTo("/notify"))); } @Test public void notifyFirstAvailableThenNotIfProductQuantityMovedFromPositiveToZero() throws Exception { stubDostavchenko("114"); stubNotification( // language=JSON "{\n" + " \"productId\": 114,\n" + " \"available\": true\n" + "}"); performQuantityUpdateRequest( // language=JSON "{\n" + " \"productId\": 114,\n" + " \"color\" : \"Yellow\",\n" + " \"productQuantity\": 10\n" + "}"); stubNotification( // language=JSON "{\n" + " \"productId\": 114,\n" + " \"available\": false\n" + "}"); performQuantityUpdateRequest( // language=JSON "{\n" + " \"productId\": 114,\n" + " \"color\" : \"Yellow\",\n" + " \"productQuantity\": 0\n" + "}"); verify(2, postRequestedFor(urlEqualTo("/notify"))); } @Test public void noNotificationOnDisabledProduct() throws Exception { stubNotification( // language=JSON "{\n" + " \"productId\": 115,\n" + " \"available\": false\n" + "}"); disableProduct(115); for (int i = 0; i < 5; i++) { performQuantityUpdateRequest( // language=JSON "{\n" + " \"productId\": 115,\n" + " \"color\" : \"Yellow\",\n" + " \"productQuantity\": " + i + "\n" + "}"); } verify(1, postRequestedFor(urlEqualTo("/notify"))); } private void disableProduct(int productId) throws Exception { mockMvc.perform( post("/disableProduct?productId=" + productId) ).andDo( print() ).andExpect( status().isOk() ); } private void performQuantityUpdateRequest(String content) throws Exception { mockMvc.perform( post("/product-quantity-update") .contentType(MediaType.APPLICATION_JSON) .content(content) ).andDo( print() ).andExpect( status().isOk() ); } private void stubNotification(String content) { stubFor(WireMock.post(urlEqualTo("/notify")) .withHeader("Content-Type", equalTo(MediaType.APPLICATION_JSON_UTF8_VALUE)) .withRequestBody(equalToJson(content)) .willReturn(aResponse().withStatus(HttpStatus.OK_200))); } private void stubDostavchenko(final String productId) { stubFor(get(urlEqualTo("/isDeliveryAvailable?productId=" + productId)) .willReturn(aResponse().withStatus(HttpStatus.OK_200).withBody("true"))); } }

बस क्या हुआ?

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

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

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

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

नियंत्रक

जब हमने एकीकरण परीक्षण लिखा और अब हमें विश्वास है कि कार्य को पारित करने के बाद, हम रात को शांति से सो सकते हैं, परतों की प्रोग्रामिंग शुरू करने का समय आ गया है। और पहली परत जिसे हम लागू करेंगे, वह नियंत्रक है। आखिर वह क्यों? क्योंकि यह कार्यक्रम का प्रवेश बिंदु है। हमें ऊपर से नीचे तक जाने की जरूरत है, पहली परत से, जिसके साथ उपयोगकर्ता अंत तक, बातचीत करेगा।
यह महत्वपूर्ण है।

और फिर, यह सब एक ही सवाल से शुरू होता है:

मुझे कंट्रोलर से क्या चाहिए?

उत्तर है:

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

मैं चाहता हूं:

अमान्य आईडी वाले उत्पाद को डिस्कनेक्ट करने का प्रयास करते समय BAD_REQUEST उपयोगकर्ता के पास वापस आ गया
BAD_REQUEST अमान्य आईडी वाले माल के परिवर्तन के बारे में सूचित करने का प्रयास करते समय
नकारात्मक मात्रा सूचित करने का प्रयास करते समय BAD_REQUEST
अगर DostavchenKO अनुपलब्ध है, तो INTERNAL_SERVER_ERROR
DATA को भेजने में असमर्थ होने पर, INTERNAL_SERVER_ERROR

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

200 अगर प्रसंस्करण सफल रहा
अन्य सभी मामलों में एक डिफ़ॉल्ट संदेश के साथ INTERNAL_SERVER_ERROR, ताकि स्टैक्रेस को न चमकाया जाए

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

परीक्षण लिखना शुरू करें

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

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

तृतीय-पक्ष डेटा सिस्टम के साथ संचार त्रुटि के लिए परीक्षण

 @RunWith(SpringRunner.class) @WebMvcTest @AutoConfigureMockMvc public class ControllerTest { @MockBean private UpdateProcessorService updateProcessorService; @Test public void returnServerErrorOnDataCommunicationError() throws Exception { doThrow(new DataCommunicationException()).when(updateProcessorService).processUpdate(any(Update.class)); performUpdate( //language=JSON "{\n" + " \"productId\": 1,\n" + " \"color\": \"red\",\n" + " \"productQuantity\": 10\n" + "}" ).andDo( print() ).andExpect( status().isInternalServerError() ).andExpect( content().json("{\n" + " \"errors\": [\n" + " {\n" + " \"message\": \"Can't communicate with Data system\"\n" + " }\n" + " ]\n" + "}") ); } }

इस स्तर पर, कई चीजें अपने आप सामने आईं:

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

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

कुल मिलाकर, नियंत्रक के लिए परीक्षण निम्नानुसार हैं:

परीक्षण

 @RunWith(SpringRunner.class) @WebMvcTest @AutoConfigureMockMvc public class ControllerTest { @InjectMocks private Controller controller; @MockBean private UpdateProcessorService updateProcessorService; @Autowired private MockMvc mvc; @Test public void returnBadRequestOnDisableWithInvalidProductId() throws Exception { mvc.perform( post("/disableProduct?productId=-443") ).andDo( print() ).andExpect( status().isBadRequest() ).andExpect( content().json(getInvalidProductIdJsonContent()) ); } @Test public void returnBadRequestOnNotifyWithInvalidProductId() throws Exception { performUpdate( //language=JSON "{\n" + " \"productId\": -1,\n" + " \"color\": \"red\",\n" + " \"productQuantity\": 0\n" + "}" ).andDo( print() ).andExpect( status().isBadRequest() ).andExpect( content().json(getInvalidProductIdJsonContent()) ); } @Test public void returnBadRequestOnNotifyWithNegativeProductQuantity() throws Exception { performUpdate( //language=JSON "{\n" + " \"productId\": 1,\n" + " \"color\": \"red\",\n" + " \"productQuantity\": -10\n" + "}" ).andDo( print() ).andExpect( status().isBadRequest() ).andExpect( content().json("{\n" + " \"errors\": [\n" + " {\n" + " \"message\": \"productQuantity is invalid\"\n" + " }\n" + " ]\n" + "}") ); } @Test public void returnServerErrorOnDostavchenkoCommunicationError() throws Exception { doThrow(new DostavchenkoException()).when(updateProcessorService).processUpdate(any(Update.class)); performUpdate( //language=JSON "{\n" + " \"productId\": 1,\n" + " \"color\": \"red\",\n" + " \"productQuantity\": 10\n" + "}" ).andDo( print() ).andExpect( status().isInternalServerError() ).andExpect( content().json("{\n" + " \"errors\": [\n" + " {\n" + " \"message\": \"DostavchenKO communication exception\"\n" + " }\n" + " ]\n" + "}") ); } @Test public void returnServerErrorOnDataCommunicationError() throws Exception { doThrow(new DataCommunicationException()).when(updateProcessorService).processUpdate(any(Update.class)); performUpdate( //language=JSON "{\n" + " \"productId\": 1,\n" + " \"color\": \"red\",\n" + " \"productQuantity\": 10\n" + "}" ).andDo( print() ).andExpect( status().isInternalServerError() ).andExpect( content().json("{\n" + " \"errors\": [\n" + " {\n" + " \"message\": \"Can't communicate with Data system\"\n" + " }\n" + " ]\n" + "}") ); } @Test public void return200OnSuccess() throws Exception { performUpdate( //language=JSON "{\n" + " \"productId\": 1,\n" + " \"color\": \"red\",\n" + " \"productQuantity\": 10\n" + "}" ).andDo( print() ).andExpect( status().isOk() ); } @Test public void returnServerErrorOnUnexpectedException() throws Exception { doThrow(new RuntimeException()).when(updateProcessorService).processUpdate(any(Update.class)); performUpdate( //language=JSON "{\n" + " \"productId\": 1,\n" + " \"color\": \"red\",\n" + " \"productQuantity\": 10\n" + "}" ).andDo( print() ).andExpect( status().isInternalServerError() ).andExpect( content().json("{\n" + " \"errors\": [\n" + " {\n" + " \"message\": \"Internal Server Error\"\n" + " }\n" + " ]\n" + "}") ); } @Test public void returnTwoErrorMessagesOnInvalidProductIdAndNegativeQuantity() throws Exception { performUpdate( //language=JSON "{\n" + " \"productId\": -1,\n" + " \"color\": \"red\",\n" + " \"productQuantity\": -10\n" + "}" ).andDo( print() ).andExpect( status().isBadRequest() ).andExpect( content().json("{\n" + " \"errors\": [\n" + " { \"message\": \"productQuantity is invalid\" },\n" + " { \"message\": \"productId is invalid\" }\n" + " ]\n" + "}") ); } private ResultActions performUpdate(String jsonContent) throws Exception { return mvc.perform( post("/product-quantity-update") .contentType(MediaType.APPLICATION_JSON_UTF8_VALUE) .content(jsonContent) ); } private String getInvalidProductIdJsonContent() { return //language=JSON "{\n" + " \"errors\": [\n" + " {\n" + " \"message\": \"productId is invalid\"\n" + " }\n" + " ]\n" + "}"; } }

अब हम कार्यान्वयन लिख सकते हैं और सुनिश्चित कर सकते हैं कि सभी परीक्षण सफलतापूर्वक पास हों:

कार्यान्वयन

 @RestController @AllArgsConstructor @Validated @Slf4j public class Controller { private final UpdateProcessorService updateProcessorService; @PostMapping("/product-quantity-update") public void updateQuantity(@RequestBody @Valid Update update) { updateProcessorService.processUpdate(update); } @PostMapping("/disableProduct") public void disableProduct(@RequestParam("productId") @Min(0) Long productId) { updateProcessorService.disableProduct(Long.valueOf(productId)); } }

अपवाद हैंडलर

 @ControllerAdvice @Slf4j public class ApplicationExceptionHandler { @ExceptionHandler(ConstraintViolationException.class) @ResponseBody @ResponseStatus(HttpStatus.BAD_REQUEST) public ErrorResponse onConstraintViolationException(ConstraintViolationException exception) { log.info("Constraint Violation", exception); return new ErrorResponse(exception.getConstraintViolations().stream() .map(constraintViolation -> new ErrorResponse.Message( ((PathImpl) constraintViolation.getPropertyPath()).getLeafNode().toString() + " is invalid")) .collect(Collectors.toList())); } @ExceptionHandler(value = MethodArgumentNotValidException.class) @ResponseBody @ResponseStatus(value = HttpStatus.BAD_REQUEST) public ErrorResponse onMethodArgumentNotValidException(MethodArgumentNotValidException exception) { log.info(exception.getMessage()); List<ErrorResponse.Message> fieldErrors = exception.getBindingResult().getFieldErrors().stream() .map(fieldError -> new ErrorResponse.Message(fieldError.getField() + " is invalid")) .collect(Collectors.toList()); return new ErrorResponse(fieldErrors); } @ExceptionHandler(DostavchenkoException.class) @ResponseBody @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR) public ErrorResponse onDostavchenkoCommunicationException(DostavchenkoException exception) { log.error("DostavchenKO communication exception", exception); return new ErrorResponse(Collections.singletonList( new ErrorResponse.Message("DostavchenKO communication exception"))); } @ExceptionHandler(DataCommunicationException.class) @ResponseBody @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR) public ErrorResponse onDataCommunicationException(DataCommunicationException exception) { log.error("DostavchenKO communication exception", exception); return new ErrorResponse(Collections.singletonList( new ErrorResponse.Message("Can't communicate with Data system"))); } @ExceptionHandler(Exception.class) @ResponseBody @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR) public ErrorResponse onException(Exception exception) { log.error("Error while processing", exception); return new ErrorResponse(Collections.singletonList( new ErrorResponse.Message(HttpStatus.INTERNAL_SERVER_ERROR.getReasonPhrase()))); } }

बस क्या हुआ?

TDD में, आपको सभी कोड अपने सिर में नहीं रखने होंगे।

चलो फिर से: रैम में पूरे आर्किटेक्चर को न रखें। सिर्फ एक परत को देखो। वह सरल है।

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

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

सेवा

अगला हम सेवा को लागू करते हैं।

हम सेवा से क्या चाहते हैं?

हम चाहते हैं कि वह व्यापारिक तर्क से निपटे, यानी:

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

बंद करो!

क्या आपको नहीं लगता कि हमारी सेवा बहुत अधिक करने लगी है?

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

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

व्यापार तर्क

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

 public boolean isAvailableForTransportation(Long productId) {...}

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

हम एक ऐसी सेवा से एक समान हस्ताक्षर चाहते हैं जो डिस्कनेक्ट किए गए माल से निपटेगा:

 public boolean isProductEnabled(Long productId) {...}

इसलिए, प्रश्न "मुझे व्यापार तर्क सेवा से क्या चाहिए?"

सेवा टेस्ट

 @RunWith(MockitoJUnitRunner.class) public class UpdateProcessorServiceTest { @InjectMocks private UpdateProcessorService updateProcessorService; @Mock private ManualExclusionService manualExclusionService; @Mock private DostavchenkoClient dostavchenkoClient; @Mock private AvailabilityNotifier availabilityNotifier; @Test public void notifyAvailableIfYellowProductIsEnabledAndReadyForTransportation() { final Update testProduct = new Update(1L, 10L, "Yellow"); when(dostavchenkoClient.isAvailableForTransportation(testProduct.getProductId())).thenReturn(true); when(manualExclusionService.isProductEnabled(testProduct.getProductId())).thenReturn(true); updateProcessorService.processUpdate(testProduct); verify(availabilityNotifier, only()).notify(eq(new ProductAvailability(testProduct.getProductId(), true))); } @Test public void notifyNotAvailableIfProductIsAbsent() { final Update testProduct = new Update(1L, 0L, "Yellow"); updateProcessorService.processUpdate(testProduct); verify(availabilityNotifier, only()).notify(eq(new ProductAvailability(testProduct.getProductId(), false))); verifyNoMoreInteractions(manualExclusionService); verifyNoMoreInteractions(dostavchenkoClient); } @Test public void notifyNotAvailableIfProductIsBlue() { final Update testProduct = new Update(1L, 10L, "Blue"); updateProcessorService.processUpdate(testProduct); verify(availabilityNotifier, only()).notify(eq(new ProductAvailability(testProduct.getProductId(), false))); verifyNoMoreInteractions(manualExclusionService); verifyNoMoreInteractions(dostavchenkoClient); } @Test public void notifyNotAvailableIfProductIsDisabled() { final Update testProduct = new Update(1L, 10L, "Yellow"); when(manualExclusionService.isProductEnabled(testProduct.getProductId())).thenReturn(false); updateProcessorService.processUpdate(testProduct); verify(availabilityNotifier, only()).notify(eq(new ProductAvailability(testProduct.getProductId(), false))); verifyNoMoreInteractions(dostavchenkoClient); } @Test public void notifyNotAvailableIfProductIsNotReadyForTransportation() { final Update testProduct = new Update(1L, 10L, "Yellow"); when(dostavchenkoClient.isAvailableForTransportation(testProduct.getProductId())).thenReturn(false); when(manualExclusionService.isProductEnabled(testProduct.getProductId())).thenReturn(true); updateProcessorService.processUpdate(testProduct); verify(availabilityNotifier, only()).notify(eq(new ProductAvailability(testProduct.getProductId(), false))); } @Test(expected = DostavchenkoException.class) public void throwCustomExceptionIfDostavchenkoCommunicationFailed() { final Update testProduct = new Update(1L, 10L, "Yellow"); when(dostavchenkoClient.isAvailableForTransportation(testProduct.getProductId())) .thenThrow(new RestClientException("Something's wrong")); when(manualExclusionService.isProductEnabled(testProduct.getProductId())).thenReturn(true); updateProcessorService.processUpdate(testProduct); } }

इस स्तर पर, वे खुद से पैदा हुए थे:

DostavchenKO ग्राहक सेवा-अनुकूल सिंगुरा के साथ
एक सेवा जिसमें आलसी भेजने के तर्क को लागू करना आवश्यक होगा, जिसे डिजाइन की गई सेवा अपने काम के परिणामों को प्रसारित करेगी
काटे गए माल और उसके हस्ताक्षर की सेवा

कार्यान्वयन:

कार्यान्वयन

 @RequiredArgsConstructor @Service @Slf4j public class UpdateProcessorService { private final AvailabilityNotifier availabilityNotifier; private final DostavchenkoClient dostavchenkoClient; private final ManualExclusionService manualExclusionService; public void processUpdate(Update update) { if (update.getProductQuantity() <= 0) { availabilityNotifier.notify(getNotAvailableProduct(update.getProductId())); return; } if ("Blue".equals(update.getColor())) { availabilityNotifier.notify(getNotAvailableProduct(update.getProductId())); return; } if (!manualExclusionService.isProductEnabled(update.getProductId())) { availabilityNotifier.notify(getNotAvailableProduct(update.getProductId())); return; } try { final boolean availableForTransportation = dostavchenkoClient.isAvailableForTransportation(update.getProductId()); availabilityNotifier.notify(new ProductAvailability(update.getProductId(), availableForTransportation)); } catch (Exception exception) { log.warn("Problems communicating with DostavchenKO", exception); throw new DostavchenkoException(); } } private ProductAvailability getNotAvailableProduct(Long productId) { return new ProductAvailability(productId, false); } }

उत्पादों को निष्क्रिय करना

अपरिहार्य टीडीडी चरणों में से एक के लिए समय आ गया है - रिफैक्टरिंग। यदि आपको याद है, नियंत्रक के कार्यान्वयन के बाद, सेवा अनुबंध इस तरह से देखा गया था:

 public void disableProduct(long productId)

और अब हमने वियोग तर्क को एक अलग सेवा में स्थानांतरित करने का निर्णय लिया।

इस स्तर पर इस सेवा से हम निम्नलिखित चाहते हैं:

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

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

सबसे पहले, आप तुरंत देख सकते हैं कि आवेदन में समस्या हो सकती है यदि कोई डिस्कनेक्ट किए गए उत्पाद को वापस करना चाहता है, क्योंकि फिलहाल यह सेवा बस यह नहीं जानती है कि यह कैसे करना है। और इसका मतलब है कि शायद इस मुद्दे पर विश्लेषक के साथ चर्चा करने के लायक है, जिन्होंने विकास के लिए कार्य निर्धारित किया है। मैं समझता हूं कि इस मामले में टीओआर के पहले पढ़ने के ठीक बाद यह सवाल उठना चाहिए था, लेकिन हम एक काफी सरल प्रणाली तैयार कर रहे हैं, बड़ी परियोजनाओं में यह इतना स्पष्ट नहीं हो सकता है। इसके अलावा, हम यह नहीं जानते थे कि हमारे पास एक इकाई होगी जो केवल सामानों की कटाई की कार्यक्षमता के लिए जिम्मेदार है: मुझे याद है कि हम केवल विकास प्रक्रिया में पैदा हुए थे।
-, . — , . , , , , , , . . ProductAvailability. , . . ., , god object, , , , TDD, , . , , «» — : « ...» , , TDD, .

 @SpringBootTest @RunWith(SpringRunner.class) public class ManualExclusionServiceTest { @Autowired private ManualExclusionService service; @Autowired private ManualExclusionRepository manualExclusionRepository; @Before public void clearDb() { manualExclusionRepository.deleteAll(); } @Test public void disableItem() { Long productId = 100L; service.disableProduct(productId); assertThat(service.isProductEnabled(productId), is(false)); } @Test public void returnEnabledIfProductWasNotDisabled() { assertThat(service.isProductEnabled(100L), is(true)); assertThat(service.isProductEnabled(200L), is(true)); } }

 @Service @AllArgsConstructor public class ManualExclusionService { private final ManualExclusionRepository manualExclusionRepository; public boolean isProductEnabled(Long productId) { return !manualExclusionRepository.exists(productId); } public void disableProduct(long productId) { manualExclusionRepository.save(new ManualExclusion(productId)); } }

, , , DATA .

, -, . . ProductAvailability, : productId isAvailable.

, :

.
, .
, .
, , , .
इसके अलावा, जब DATA की ओर से निष्पादित किया जाता है, तो सेवा को अपने DataCommunicationException को फेंकने की आवश्यकता होती है।

यहां सब कुछ अपेक्षाकृत सरल है, लेकिन मैं एक बिंदु पर ध्यान देना चाहूंगा:

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

ProductAvucation ऑब्जेक्ट को सहेजने के लिए उपयुक्त नहीं है, क्योंकि कम से कम कोई पहचानकर्ता नहीं है, जिसका अर्थ है कि किसी अन्य को बनाना तर्कसंगत है। यहाँ मुख्य बात यह नहीं है कि इस पहचानकर्ता को @Document (हम आधार के रूप में MongoDb का उपयोग करेंगे) और ProductAvucation में अनुक्रमित करने के लिए एक साथ नहीं जोड़ेंगे।

आपको यह समझने की जरूरत है कि सभी कुछ क्षेत्रों के साथ ProductAvucation ऑब्जेक्ट डिजाइनिंग कक्षाओं के चरण में बनाया गया था, जो कि वर्तमान में हम डिजाइन कर रहे हैं की तुलना में कॉल पदानुक्रम में अधिक हैं। इन वर्गों को डेटाबेस-विशिष्ट क्षेत्रों के बारे में कुछ भी जानने की आवश्यकता नहीं है, क्योंकि डिजाइन करते समय यह जानकारी आवश्यक नहीं थी।

लेकिन यह सब बात है।

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

परीक्षण

 @RunWith(SpringRunner.class) @SpringBootTest public class LazyAvailabilityNotifierTest { @Autowired private LazyAvailabilityNotifier lazyAvailabilityNotifier; @MockBean @Qualifier("dataClient") private AvailabilityNotifier availabilityNotifier; @Autowired private AvailabilityRepository availabilityRepository; @Before public void clearDb() { availabilityRepository.deleteAll(); } @Test public void notifyIfFirstTime() { sendNotificationAndVerifyDataBase(new ProductAvailability(1L, false)); } @Test public void notifyIfAvailabilityChanged() { final ProductAvailability oldProductAvailability = new ProductAvailability(1L, false); sendNotificationAndVerifyDataBase(oldProductAvailability); final ProductAvailability newProductAvailability = new ProductAvailability(1L, true); sendNotificationAndVerifyDataBase(newProductAvailability); } @Test public void doNotNotifyIfAvailabilityDoesNotChanged() { final ProductAvailability productAvailability = new ProductAvailability(1L, false); sendNotificationAndVerifyDataBase(productAvailability); sendNotificationAndVerifyDataBase(productAvailability); sendNotificationAndVerifyDataBase(productAvailability); sendNotificationAndVerifyDataBase(productAvailability); verify(availabilityNotifier, only()).notify(eq(productAvailability)); } @Test public void doNotSaveIfSentWithException() { doThrow(new RuntimeException()).when(availabilityNotifier).notify(anyObject()); boolean exceptionThrown = false; try { availabilityNotifier.notify(new ProductAvailability(1L, false)); } catch (RuntimeException exception) { exceptionThrown = true; } assertTrue("Exception was not thrown", exceptionThrown); assertThat(availabilityRepository.findAll(), hasSize(0)); } @Test(expected = DataCommunicationException.class) public void wrapDataException() { doThrow(new RestClientException("Something wrong")).when(availabilityNotifier).notify(anyObject()); lazyAvailabilityNotifier.notify(new ProductAvailability(1L, false)); } private void sendNotificationAndVerifyDataBase(ProductAvailability productAvailability) { lazyAvailabilityNotifier.notify(productAvailability); verify(availabilityNotifier).notify(eq(productAvailability)); assertThat(availabilityRepository.findAll(), hasSize(1)); assertThat(availabilityRepository.findAll().get(0), hasProperty("productId", is(productAvailability.getProductId()))); assertThat(availabilityRepository.findAll().get(0), hasProperty("availability", is(productAvailability.isAvailable()))); } }

कार्यान्वयन

 @Component @AllArgsConstructor @Slf4j public class LazyAvailabilityNotifier implements AvailabilityNotifier { private final AvailabilityRepository availabilityRepository; private final AvailabilityNotifier availabilityNotifier; @Override public void notify(ProductAvailability productAvailability) { final AvailabilityPersistenceObject persistedProductAvailability = availabilityRepository .findByProductId(productAvailability.getProductId()); if (persistedProductAvailability == null) { notifyWith(productAvailability); availabilityRepository.save(createObjectFromProductAvailability(productAvailability)); } else if (persistedProductAvailability.isAvailability() != productAvailability.isAvailable()) { notifyWith(productAvailability); persistedProductAvailability.setAvailability(productAvailability.isAvailable()); availabilityRepository.save(persistedProductAvailability); } } private void notifyWith(ProductAvailability productAvailability) { try { availabilityNotifier.notify(productAvailability); } catch (RestClientException exception) { log.error("Couldn't notify", exception); throw new DataCommunicationException(); } } private AvailabilityPersistenceObject createObjectFromProductAvailability(ProductAvailability productAvailability) { return new AvailabilityPersistenceObject(productAvailability.getProductId(), productAvailability.isAvailable()); } }

निष्कर्ष

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

विभिन्न तकनीकों का उपयोग करके एक ही एप्लिकेशन लिखकर, मैं उनके मतभेदों की सराहना कर सकता हूं। अपने अभ्यास में, मैंने देखा कि टीडीडी वास्तुकला को बनाने में कैसे मदद करता है, यह मुझे लगता है, अधिक सही ढंग से।

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

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

और सामान्य तौर पर, एक भावना थी कि एक डेवलपर के रूप में मैं बेहतर बन गया।

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

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

एप्लिकेशन कोड ज्सन की तरह एक स्वरूपित स्ट्रिंग का पुन: उपयोग करता है। यह जांचना आवश्यक है कि आवेदन POJO ऑब्जेक्ट्स पर json को पार्स कैसे करेगा। यदि आप IDEA का उपयोग करते हैं, तो जल्दी और बिना दर्द के JSON भाषा इंजेक्शन का उपयोग करके आवश्यक स्वरूपण प्राप्त किया जा सकता है।

दृष्टिकोण के नुकसान क्या हैं?

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

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

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

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

खैर, आखिरी। यदि आप TDD का उपयोग करते हैं और आपका कोड अभी भी बहुत नहीं है, तो मामला कार्यप्रणाली में नहीं हो सकता है। लेकिन इससे मुझे मदद मिली।

परीक्षण-संचालित विकास का उपयोग करके एक चिकित्सक पर पैसे कैसे बचाएं

फिर से टीडीडी क्या है

व्यावहारिक कार्य

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

परीक्षण भरना शुरू करें

बस क्या हुआ?

नियंत्रक

परीक्षण लिखना शुरू करें

बस क्या हुआ?

सेवा

व्यापार तर्क

उत्पादों को निष्क्रिय करना

निष्कर्ष

दृष्टिकोण के नुकसान क्या हैं?

More articles: