वास्तविक जीवन में परीक्षण कोड के लिए दृष्टिकोण। भाग दो

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

हम अनुरोधों का परीक्षण करना जारी रखते हैं

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

public void test() { Application app1 = ApplicationMother.makeApplication(); Version version11 = VersionMother.makeVersion(app1); save(app1, version11); DeploymentMother.makeDeployment(app1); DeploymentMother.makeDeployment(app1); //   4  List<ResultRow> result = myRepository.executeComplicatedQuery(); assertEquals(app1.getId(), result.get(0).getAppId()); assertEquals(version11.getId(), result.get(0).getVersionId()); assertEquals(2, result.get(0).getDeploymentCount()); //      } //   19        

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

 public void testDeletedDeploymentsDontCount() { TestData data = app("app 1") .withNonDeletedVersion().deployedTimes(2) .withDeletedVersions(1).deployedTimes(2) .app("app 2") .withNonDeletedVersion().deployedTimes(1); queryAndAssert( data.makeExpectedRow(1, 1, 2), data.makeExpectedRow(1, 2, 0), data.makeExpectedRow(2, 1, 0) ); //  TestData.makeExpectedRow  : //    ,    ,    deployment-. 

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

 TestData data = times(5).deployedAppAndVersion() .times(2).deletedDeployedApp(); 

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

• अनुरोध का पहला संस्करण लिखना: 20 मिनट।
• पहले दो परीक्षण लिखना: 10 मिनट।
• तीसरा परीक्षण लिखना, शपथ लेना, जो बदसूरत और असुविधाजनक है: 10 मिनट।
• नंबर 1: 30 मिनट को फिर से सक्रिय करना।
• परीक्षण 4-8 लिखना, नंबर 2 को फिर से दिखाना: 10 मिनट।
• अनुरोध को फिर से लिखना, क्योंकि अंजीर ने काम नहीं किया, यह पता चला है, और सभी परीक्षणों का सफल प्रक्षेपण: 20 मिनट।
• अधिक परीक्षणों को जोड़ना, परीक्षणों को फिर से भरना, अनुरोध को ठीक करना: 10 मिनट के लिए 4 बार।

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

तृतीय-पक्ष सेवाओं के साथ परीक्षण सहभागिता

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

 // VirtualInfrastructureManager -  ,     public class VirtualInfrastructureManagerStub implements VirtualInfrastructureManager { private List<VirtualMachineState> vms; public VirtualMachineState createVm(VirtualMachineDescription vmDescription) { vms.add(makeVm(vmDescription)); } public List<VirtualMachineState> pollForStatuses() { return vms; } //,   .   } 

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

 public void testDeploymentStarted() { Deployment deployment = DeploymentMother.makeNewDeployment(); deploymentManager.startDeployment(deployment); assertDeploymentGoesThroughStatuses(NEW, STARTING, CONFIGURING, RUNNING); } 

इसे और भी दिलचस्प बनाने के लिए, आप हमारे स्टब में कैओस बंदर को जोड़ सकते हैं।

 public class VirtualInfrastructureManagerStubWithChaosMonkey implements VirtualInfrastructureManager { private ChaosMonkey monkey; public VirtualMachineState createVm(VirtualMachineDescription vmDescription) { monkey.rollTheDice(); vms.add(makeVm(vmDescription)); } ... private class ChaosMonkey { public void rollTheDice() { if (iAmEvil()) throw new VirtualInfrastructureException("Ha-ha!"); return; } } } 

कल्पना करें कि अगर बंदर से त्रुटि की संभावना पूछी जा सकती है तो आप कितनी दिलचस्प परिस्थितियाँ बना सकते हैं। या अगर वह समय-समय पर यादृच्छिक कानून द्वारा हमारी आभासी मशीनों को "मारता है"?

 public void testRunningDeploymentRecovers() { Deployment deployment = startDeploymentAndAssertRunning(); ((VirtualInfrastructureManagerStubWithChaosMonkey)virtualInfrastructureManager) .getChaosMonkey().killVms(1); assertDeploymentGoesThroughStatuses(BROKEN, RECOVERING, RUNNING); } 

और हमें यह सब मज़ा सीधे हमारी मशीन पर मिलता है, प्रत्येक वर्चुअल मशीन को शुरू करने के लिए पांच मिनट तक इंतजार किए बिना, एक कॉर्पोरेट वीपीएन से कनेक्ट करने की आवश्यकता के बिना।

लघु विषयांतर: निरंतर एकीकरण

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

पूरे आवेदन का परीक्षण

यह सब, ज़ाहिर है, अद्भुत है, लेकिन शांति से सोने के लिए, हमें यह सुनिश्चित करने की आवश्यकता है कि हमारा आवेदन पूरी तरह से काम करता है, न कि केवल इसके व्यक्तिगत टुकड़े। इसके अलावा, यदि प्रत्येक व्यक्तिगत मॉड्यूल और उनके संयोजन परीक्षणों द्वारा अच्छी तरह से कवर किए गए हैं, तो हमें काम के हर पहलू की जांच करने की आवश्यकता नहीं है, ताकि एक ही काम को दो बार नहीं करना पड़े। यहां आपके उत्पाद के लिए तकनीकी विशिष्टताओं को फिर से संदर्भित करना उपयोगी है। उदाहरण के लिए, कहानियों में से एक (उपयोगकर्ता कहानी) पढ़ी गई: "एक उपयोगकर्ता के रूप में, मैं एक एप्लिकेशन को चलाने में सक्षम होना चाहता हूं जिसके लिए मास्टर-स्लेव प्रतिकृति मोड में MySQL की आवश्यकता होती है।" हमारे पास परीक्षण हैं जो एप्लिकेशन के लोडिंग की जांच करते हैं, ऐसे परीक्षण हैं जो उन सूचनाओं की शुद्धता की गारंटी देते हैं जो हम प्रत्येक मामले के लिए प्रत्येक वर्चुअल मशीन को भेजते हैं। लेकिन कोड ही, जो एक आभासी मशीन में सभी आवश्यक सॉफ़्टवेयर को कॉन्फ़िगर करेगा, सबसे पहले, अन्य लोगों द्वारा लिखा गया है, और, दूसरी बात, दूसरी भाषा में। हम इस मामले में क्या करते हैं? मूर्खतापूर्वक कहानी के वर्णन का पालन करें। यह कहता है "मेरे आवेदन के लिए एक मास्टर-दास की आवश्यकता है" - कृपया। हम दो JSP पृष्ठों से मिलकर एक आदिम वेब एप्लिकेशन लिख रहे हैं। एक पृष्ठ पर, हम मास्टर को एक JDBCConnection बनाते हैं, और डेटाबेस में एक निश्चित प्रविष्टि लिखते हैं। दूसरे पृष्ठ पर, गुलाम के लिए एक JDBCConnection बनाएँ, और पढ़ें। इस परीक्षण एप्लिकेशन को बनाने के लिए आवश्यक समय 10 मिनट है। हमारा परीक्षण इस एप्लिकेशन को हमारे उत्पाद में लोड करता है, इसे वांछित मोड में चलाने के लिए कहता है, और फिर पहले पृष्ठ को HTTP के माध्यम से और फिर दूसरे तक पहुँचाता है। यदि वांछित पाठ दूसरे पृष्ठ पर दिखाई दिया - सब कुछ क्रम में है। यदि आप रचनात्मक रूप से आवश्यकताओं की सूची में आते हैं, तो ऐसे पूर्ण परीक्षणों की बहुत कम आवश्यकता होगी। लेकिन कल्पना करें कि जब हम आभासी मशीनों को चलाने के लिए अन्य ऑपरेटिंग सिस्टमों में से कुछ के लिए समर्थन जोड़ने का आदेश दे रहे हैं तो यह कितनी बड़ी मदद है!

वेब यूआई परीक्षण

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

निष्कर्ष

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

• परीक्षण "बात कर" होना चाहिए, परीक्षण स्वयं संभव के रूप में आदिम होना चाहिए। आपको एक से अधिक बार उसके पास वापस आना होगा और फिर से समझने की कोशिश करनी चाहिए कि उसे क्या जांचना चाहिए। यह केवल कोड को पढ़ने के लिए आवश्यक से अधिक समय नहीं लेना चाहिए
• आपकी टीम में सबसे अच्छा प्रोग्रामर को जटिल चीजों के परीक्षण के लिए एक सुविधाजनक बुनियादी ढाँचा बनाना और सुधारना चाहिए। उदाहरण के लिए, assertDeploymentGoesThroughStatuses (Dep तैनातीStatus ... allowStatuses) विधि बिल्कुल सरल नहीं है। होमवर्क छद्म कोड पर इस तरह की एक विधि लिखने के लिए है, यह देखते हुए कि आवेदन बहुस्तरीय है, और प्रत्येक चरण को एक अलग थ्रेड में किया जाना चाहिए और अनिश्चित काल तक ले जाना चाहिए :)
• केवल वही परखें जो आपको परखने की आवश्यकता है। बीस परीक्षण लिखने वाले गेटर्स और वासियों को लिखने के लिए, आपको अपने हाथ हटाने की जरूरत है
• कहीं न कहीं टिप्पणियों में मुझे वह राय मिली जो आपको अपने परीक्षणों की संरचना के माध्यम से सोचने की जरूरत है, और आम तौर पर योजना। मैं स्पष्ट रूप से वस्तु। परीक्षण लिखने की बाधा न्यूनतम होनी चाहिए। बस परीक्षण लिखना शुरू करें। यदि कल आपको उनकी संरचना को बदलने की आवश्यकता है - परिवर्तन। रीफैक्टरिंग परीक्षण के रूप में लागू है क्योंकि यह सब कुछ के लिए है।
• परीक्षण का कोई भी टुकड़ा जो दो बार होता है - इसे एक अलग विधि में डालने के लिए स्वतंत्र महसूस करें (उदाहरण के लिए, TestUtils में)। यह आपके स्टाफ सदस्य द्वारा आपके अगले परीक्षण को लिखने में बाधा को कम करता है।
• परीक्षण के किसी भी टुकड़े को बाहर निकालें जो कि बहुत सामान्य दिखता है (उदाहरण के लिए, AsUrequals (2, तैनाती) size ()) TestUtils में (assertSize (अपेक्षित, संग्रह))। कोड को यह कहना चाहिए कि वह क्या करता है।
• यदि कोड का एक टुकड़ा परीक्षण करना मुश्किल है, तो यह सबसे खराब रूप से लिखा जाने की संभावना है। सिद्धांत रूप में, पहले एक परीक्षण लिखना आवश्यक है, और फिर कोड जो इस परीक्षण का परीक्षण करता है। यह कोशिश करो, आप इसे पसंद करेंगे।
• और सबसे महत्वपूर्ण बात यह है कि परीक्षण लिखना एक उबाऊ दायित्व नहीं है, लेकिन बस लेखन कोड के लिए सही दृष्टिकोण है जो आपको उबाऊ दिनचर्या के बजाय वास्तव में दिलचस्प समस्याओं के बारे में सोचने की अनुमति देता है।