और फिर से परीक्षणों के बारे में। वास्तविक जीवन परीक्षण दृष्टिकोण

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

^*) स्वयं परीक्षण लिखना वास्तव में प्राथमिक है। एक बुनियादी ढांचा बनाना जो परीक्षण लिखना आसान बनाता है, थोड़ा और अधिक जटिल है।


मैं एक सिद्धांतवादी नहीं हूँ, मैं एक अभ्यासी हूँ ("मैं स्वभाव से पुश्किन नहीं हूँ, मैं बेलिंस्की हूँ" ©)। इसलिए, मैं टेस्ट ड्रिवेन डेवलपमेंट, डेटा ड्रिवेन डेवलपमेंट, बिहेवियर ड्रिवेन डेवलपमेंट के कुछ विचारों का उपयोग करूंगा, लेकिन मैं हमेशा अपनी पसंद को सही नहीं ठहरा सकता। मूल रूप से, मेरा तर्क होगा: "यह आसान है," या "यह अधिक सुविधाजनक है।" यह अच्छी तरह से जानते हुए कि मेरे व्यंजनों को सभी के लिए उपयुक्त नहीं है, मैं पूछता हूं, सबसे पहले, सभी एक ही, मेरे तर्क पर विचार करने के लिए, और दूसरी बात, इस पाठ को पाठ्यपुस्तक के रूप में नहीं मानें।

तो, ड्रम रोल:

परिष्कृत आवेदन

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

वसंत और परीक्षण। मॉक टेस्ट के साथ व्यावसायिक तर्क का परीक्षण

वसंत अनुप्रयोगों का परीक्षण करना बहुत आसान है। स्प्रिंग का उपयोग करने का एक कारण यह है कि इसके साथ परीक्षण करना आसान है। “एक खरगोश वह है जो एक छेद में रहता है। नोरा वह जगह है जहाँ खरगोश रहता है ”©

इंटरफेस:

public interface DeploymentService { Deployment deploy(Application application, DeploymentDescription deploymentDescription); } 

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

 @Service public class DeploymentServiceImpl implements DeploymentService { private DeploymentRepository deploymentRepository; private DeploymentMaker deploymentMaker; private VirtualInfrastructureService virtualInfrastructureService; @Autowired public DeploymentServiceImpl(DeploymentRepository deploymentRepository, DeploymentMaker deploymentMaker, VirtualInfrastructureService virtualInfrastructureService) { this.deploymentRepository = deploymentRepository; this.deploymentMaker = deploymentMaker; this.virtualInfrastructureService = virtualInfrastructureService; } public Deployment deploy(Application application, DeploymentDescription deploymentDescription) { //   Deployment Deployment deployment = deploymentMaker.makeDeployment(application, deploymentDescription); deploymentRepository.save(deployment); try { virtualInfrastructureService.launchVirtualMachines(deployment.getVirtualMachineDescriptors()); } catch (VirtualInfrastructureException e) { throw new DeploymentUnsuccsessfullException(e); } return deployment; } } 

सिद्धांत रूप में, यह स्पष्ट है कि यह क्या करता है। बेशक, वास्तविक कोड थोड़ा अधिक जटिल है, लेकिन बहुत अधिक नहीं है। सबसे पहले, हम JMock मॉक लाइब्रेरी का उपयोग करके माथे में Dep तैनातीService.deploy () विधि का परीक्षण करते हैं

 public class DeploymentServiceMockTest extends MockObjectTestCase { private DeploymentRepository deploymentRepository = mock(DeploymentRepository.class); private DeploymentMaker deploymentMaker = mock(DeploymentMaker.class); private VirtualInfrastructureService virtualInfrastructureService = mock(VirtualInfrastructureService.class); private DeploymentServiceImpl deploymentService; public void setUp() { deploymentService = new DeploymentServiceImpl(deploymentRepository, deploymentMaker, virtualInfrastructureService); } public void testSuccessfulDeploymentSavedAndVMsLaunched() { final Application app = makeValidApplication(); final DeploymentDescription dd = makeValidDeploymentDescription(); final Deployment deployment = helperMethodToCreateDeployment(); checking(new Expectations(){{ one(deploymentMaker).makeDeployment(app, dd);will(returnValue(deployment)); one(deploymentRepository).save(deployment); one(virtualInfrastructureService).launchVirtualMachines(deployment.getVirtualMachineDescriptors()); }}); deploymentService.deploy(application, deploymentDescription); } public void testExceptionIsTranslated() { final Application app = makeValidApplication(); final DeploymentDescription dd = makeValidDeploymentDescription(); final Deployment deployment = helperMethodToCreateDeployment(); checking(new Expectations(){{ one(deploymentMaker).makeDeployment(app, dd);will(returnValue(deployment)); one(deploymentRepository).save(deployment); one(virtualInfrastructureService).launchVirtualMachines(deployment.getVirtualMachineDescriptors());will(throwException(new VirtualInfrastructureException("error message"))); }}); ` try { deploymentService.deploy(application, deploymentDescription); fail("Expected DeploymentUnsuccsessfullException!"); } catch (DeploymentUnsuccsessfullException e) { //expected } } 

क्या महत्वपूर्ण और दिलचस्प है? सबसे पहले, मॉक टेस्ट हमें अलग-अलग तरीकों का परीक्षण करने की अनुमति देते हैं, जो इन तरीकों को कहते हैं। दूसरे, लेखन परीक्षण कोड की संरचना को बहुत प्रभावित करते हैं। परिनियोजन का पहला संस्करण () विधि, निश्चित रूप से, परिनियोजनमेकर.makeDeployment () को कॉल नहीं करता है, लेकिन परिनियोजन सेवा के अंदर एक ही विधि है। जब मैंने परीक्षण लिखना शुरू किया, तो मैंने पाया कि इस स्तर पर मुझे उन सभी विकल्पों के लिए परीक्षण लिखने में कोई दिलचस्पी नहीं थी जो मेकअप करते हैं। उन्हें तैनाती () विधि में कार्यों से कोई लेना-देना नहीं है, जिसे बस डेटाबेस में एक नई वस्तु लिखने और वर्चुअल मशीन बनाने की प्रक्रिया शुरू करने की आवश्यकता है। इसलिए मैंने एक अलग सहायक वर्ग में मेकडाईपरेशन () लॉजिक निकाला। मैं इसे पूरी तरह से अलग-अलग तरीकों से परीक्षण करूंगा, क्योंकि आवेदन की स्थिति और तैनाती वस्तुएं इसके लिए मायने रखती हैं। इसके अलावा, मैंने पाया कि डिप्लॉयमेकर का परीक्षण करने के बाद, मैं परीक्षण डेटा बनाने के लिए अन्य परीक्षणों में इसका उपयोग कर सकता हूं। वैसे, JMock में न केवल इंटरफेस के लिए, बल्कि ऑब्जेक्ट इंस्टेंस के लिए भी मोकी बनाने की क्षमता है। ऐसा करने के लिए, setIpostorizer (ClassImpostorizer.INSTANCE) को setUp () में जोड़ें। मुझे यकीन है कि अन्य नकली पुस्तकालयों में भी कुछ ऐसा ही है।

इस सेवा को पूरा करने के लिए, यह बना रहता है:

डेटाबेस इंटरेक्शन परीक्षण

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

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

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

 public class DeploymentRepositoryTest extends HibernatePersistenceTest { @Autorwired private DeploymentRepository deploymentRepository; public void testSaveAndLoad() { Deployment deployment = DeploymentMother.makeSimpleDeployment(); deploymentRepository.add(deployment); Deployment loadedDeployment = deploymentRepository.getById(deployment.getId()); assertDeploymentEquals(deployment, loadedDeployment); } private void assertDeploymentEquals(Deployment expected, Deployment actual) { //    .   -  Deployment.equals(...),     //  EqualsBuilder (,   Apache Commons-lang).    id. } } 

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

हाइबरनेट के साथ काम करते समय, जटिल प्रश्नों को लिखते समय मज़ेदार भाग शुरू होता है। हम एक बहुत ही उपयोगी पुस्तकालय Arid pojos ( ORMUnit के रूप में एक ही लेखक) का उपयोग करते हैं, जो आपको एक ही प्रकार के अनुरोध कोड का एक बड़ा गुच्छा लिखने की अनुमति नहीं देता है। उदाहरण के लिए, चलाने के लिए तैयार सभी तैनाती का चयन करने के लिए, यह पर्याप्त है) हाइबरनेट मैपिंग में findDeploymentsReadyToLaunch नामक एक क्वेरी लिखें, और सूची को परिभाषित करें <Deployment> findDloymentsReadyToLaunch () विधि परिनियोजनरचनात्मक इंटरफ़ेस में। और यह सब, जब शुष्क-पॉजोस शुरू करते हैं, तो यह कोड उत्पन्न करेगा जो इस विशेष अनुरोध को चलाएगा। फिर से, हम पुस्तकालयों का परीक्षण नहीं करते हैं, इसलिए यह हमारे लिए परीक्षण डेटा बनाने और यह सुनिश्चित करने के लिए पर्याप्त है कि जो हम उम्मीद करते हैं वह डेटाबेस से वापस आ गया है। Dep तैनातीRepositoryTest में जोड़ें:

 public void testRetrieveReadyToLaunch() { for (int i=0; i<5; i++) { deploymentRepository.add(DeploymentMother.makeReadyToLaunchDeployment()); } deploymentRepository.add(DeploymentMother.makeNewDeployment()); List<Deployment> result = deploymentRepository.findDeploymentsReadyToLaunch(); assertEquals(5, result.size()); for (Deployment d : result) { assertTrue(deployment.isReadyToLaunch()); } //,    ,    ,    , ? } 

एक छोटा विषयांतर: पिछले उदाहरणों में समस्याएं

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

इसके अलावा, जोर (5, result.size ()) - यह समझने के लिए थोड़ा प्रयास करने की आवश्यकता है कि प्रोग्रामर क्या कहना चाहता था। इसके बजाय, अपने TestUtils (आप TestUtils, सही है!) में एक मुखर (int अपेक्षित, संग्रह संग्रह) विधि बनाना बेहतर है। या बेहतर अभी तक:

TestUtils में:

 public static void T assertCollection(int expectedSize, ElementAsserter<T> asserter, Collection<T> actual) { assertSize(expectedSize, actual.size()); for (T element : actual) { asserter.assertElement(element); } } public static abstract class ElementAsserter<T> { public void assertElement(T element) { if (!checkElement(element)) fail(getFailureDescription(element)); } protected abstract boolean checkElement(T element); //  ,           protected String getFailureDescription(T element) { return "  "; } } 

और फिर हमारे परीक्षण में हम यह कर सकते हैं:

  ElementAsserter readyToLaunch = new ElementAsserter<Deployment>() { protected boolean checkElement(Deployment d) { return d.isReadyToLaunch(); } protected String getFailureDescription(Deployment d) { return String.format("Deployment with id %d and name %s is NOT ready to be launched!"); } } private void assertAllReadyToLaunch(int expectedSize, List<Deployment> deployments) { TestUtils.assertCollection(expectedSize, a, deployments); } public void testOnlyReadyToLaunchDeploymentsRetrieved() { for (int i=0; i<5; i++) { deploymentRepository.add(DeploymentMother.makeReadyToLaunchDeployment()); } deploymentRepository.add(DeploymentMother.makeNewDeployment()); assertAllReadyToLaunch(5, deploymentRepository.findDeploymentsReadyToLaunch()); } 

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

और फिर?

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