श्रृंखला में तीसरा लेख और मुख्य श्रृंखला से एक छोटी शाखा - इस बार मैं दिखाऊंगा कि स्प्रिंग इंटीग्रेशन टेस्टिंग लाइब्रेरी कैसे काम करती है और यह कैसे काम करती है, परीक्षण शुरू होने पर क्या होता है और आप परीक्षण के लिए आवेदन और उसके वातावरण को कैसे ठीक कर सकते हैं।

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

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

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

वसंत परीक्षण

स्प्रिंग टेस्ट स्प्रिंग फ्रेमवर्क में शामिल पुस्तकालयों में से एक है, वास्तव में, एकीकरण परीक्षण के बारे में प्रलेखन खंड में वर्णित सब कुछ बस इसके बारे में है। पुस्तकालय हल करने वाले चार मुख्य कार्य हैं:

परीक्षणों के बीच स्प्रिंग IoC कंटेनरों और उनके कैशिंग का प्रबंधन करें
परीक्षण कक्षाओं के लिए निर्भरता इंजेक्शन प्रदान करें
एकीकरण परीक्षण के लिए उपयुक्त लेनदेन प्रबंधन प्रदान करें
डेवलपर को एकीकरण परीक्षण लिखने में मदद करने के लिए आधार कक्षाओं का एक सेट प्रदान करें

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

जीवन चक्र का परीक्षण करें

एक परीक्षण का जीवन चक्र इस तरह दिखता है:

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

परीक्षणों के प्रबंधन के सभी गंदे काम, वास्तव में, spring-test द्वारा किए जाते हैं, और Spring Boot Test बदले में, कई सहायक वर्गों को जोड़ता है, जैसे परिचित @DataJpaTest और @SpringBootTest , उपयोगी TestPropertyValues जैसे TestPropertyValues को गतिशील रूप से संदर्भ गुण बदलने के लिए। यह आपको एप्लिकेशन को एक वास्तविक वेब-सर्वर के रूप में चलाने की अनुमति देता है, या मॉक-एनवायरनमेंट (HTTP के माध्यम से पहुंच के बिना) के रूप में, @MockBean , आदि का उपयोग करके सिस्टम घटकों को पोंछना सुविधाजनक है।

संदर्भ कैशिंग

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

 @SpringBootTest @ActiveProfiles("test") @TestPropertySource("foo=bar") class FirstTest { } @SpringBootTest @ActiveProfiles("test") @TestPropertySource("foo=bar") class SecondTest { }

कैश में संदर्भों की संख्या 32 तक सीमित है - आगे, LRSU सिद्धांत के अनुसार, उनमें से एक को कैश से हटा दिया जाएगा।

कैश से संदर्भ का पुन: उपयोग करने और एक नया निर्माण करने से स्प्रिंग टेस्ट को क्या रोका जा सकता है?

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

@MockBean
एक बहुत ही स्पष्ट विकल्प, मैंने इसे अलग से भी प्रस्तुत किया - @MockBean असली बीन को एक मॉक के संदर्भ में प्रतिस्थापित करता है जिसे मॉकिटो के माध्यम से परीक्षण किया जा सकता है (निम्नलिखित लेखों में मैं दिखाऊंगा कि इसका उपयोग कैसे करें)। मुख्य बिंदु यह है कि यह एनोटेशन एप्लिकेशन में सेम के सेट को बदलता है और एक नया संदर्भ बनाने के लिए स्प्रिंग टेस्ट को मजबूर करता है। यदि हम पिछले उदाहरण लेते हैं, उदाहरण के लिए, दो संदर्भ पहले से ही यहां बनाए जाएंगे:

 @SpringBootTest @ActiveProfiles("test") @TestPropertySource("foo=bar") class FirstTest { } @SpringBootTest @ActiveProfiles("test") @TestPropertySource("foo=bar") class SecondTest { @MockBean CakeFinder cakeFinderMock; }

@TestPropertySource
कोई भी संपत्ति परिवर्तन स्वचालित रूप से कैश कुंजी को बदल देता है और एक नया संदर्भ बनाया जाता है।

@ActiveProfiles
सक्रिय प्रोफाइल बदलने से कैश पर भी असर पड़ेगा।

@ContextConfiguration
और निश्चित रूप से, कोई भी कॉन्फ़िगरेशन परिवर्तन एक नया संदर्भ भी बनाएगा।

हम आधार शुरू करते हैं

तो अब इस सारे ज्ञान के साथ हम कोशिश करेंगे ~~उतार दो~~ समझें कि आप डेटाबेस को कैसे और कहाँ चला सकते हैं। यहां एक भी सही उत्तर नहीं है, यह आवश्यकताओं पर निर्भर करता है, लेकिन आप दो विकल्पों के बारे में सोच सकते हैं:

कक्षा में सभी परीक्षणों से पहले एक बार चलाएं।
प्रत्येक कैश्ड संदर्भ के लिए एक यादृच्छिक उदाहरण और एक अलग डेटाबेस चलाएँ (संभवतः एक से अधिक वर्ग)।

आवश्यकताओं के आधार पर, आप कोई भी विकल्प चुन सकते हैं। यदि मेरे मामले में, Postgres अपेक्षाकृत जल्दी शुरू होता है और दूसरा विकल्प उपयुक्त दिखता है, तो पहले वाला कुछ अधिक कठिन हो सकता है।

पहला विकल्प स्प्रिंग से बंधा नहीं है, बल्कि एक परीक्षण ढांचे के लिए है। उदाहरण के लिए, आप JUnit 5 के लिए अपना एक्सटेंशन बना सकते हैं।

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

ApplicationContextInitializer इंटरफ़ेस स्प्रिंग में लॉन्च करने से पहले संदर्भ के साथ क्रिया करने के लिए ज़िम्मेदार है।

ApplicationContextInitializer

इंटरफ़ेस में केवल एक initialize विधि है, जिसे संदर्भ "प्रारंभ" से पहले निष्पादित किया जाता है (अर्थात, refresh विधि को कॉल करने से पहले) और आपको संदर्भ में बदलाव करने की अनुमति देता है - डिब्बे, गुण जोड़ें।

मेरे मामले में, वर्ग इस तरह दिखता है:

 public class EmbeddedPostgresInitializer implements ApplicationContextInitializer<GenericApplicationContext> { @Override public void initialize(GenericApplicationContext applicationContext) { EmbeddedPostgres postgres = new EmbeddedPostgres(); try { String url = postgres.start(); TestPropertyValues values = TestPropertyValues.of( "spring.test.database.replace=none", "spring.datasource.url=" + url, "spring.datasource.driver-class-name=org.postgresql.Driver", "spring.jpa.hibernate.ddl-auto=create"); values.applyTo(applicationContext); applicationContext.registerBean(EmbeddedPostgres.class, () -> postgres, beanDefinition -> beanDefinition.setDestroyMethodName("stop")); } catch (IOException e) { throw new RuntimeException(e); } } }

यहाँ होने वाली पहली बात यह है कि एम्बेडेड पोस्टग्रैड्स को yandex-qatools / postgresql- एम्बेडेड लाइब्रेरी से लॉन्च किया जाता है। फिर, गुणों का एक सेट बनाया गया है - नए लॉन्च किए गए आधार के लिए JDBC URL, ड्राइवर प्रकार और स्कीम के लिए हाइबरनेट व्यवहार (स्वचालित रूप से बनाएं)। एक गैर-स्पष्ट चीज़ केवल spring.test.database.replace=none - यह वही है जो हम DataJpaTest को बताते हैं कि हमें H2 जैसे एम्बेडेड डेटाबेस से कनेक्ट करने का प्रयास नहीं करना है, और हमें DataSource बिन (यह कार्य) को बदलने की आवश्यकता नहीं है।

और एक अन्य महत्वपूर्ण बिंदु application.registerBean(…) । सामान्य तौर पर, यह बीन, निश्चित रूप से पंजीकृत नहीं हो सकता है - यदि कोई इसका उपयोग आवेदन में नहीं करता है, तो इसकी विशेष रूप से आवश्यकता नहीं है। संदर्भ नष्ट होने पर स्प्रिंग को कॉल करने की विधि को निर्दिष्ट करने के लिए पंजीकरण की आवश्यकता होती है, और मेरे मामले में, और इस मामले में, यह विधि postgres.stop() को कॉल करेगी और डेटाबेस को रोक देगी।

सामान्य तौर पर, यह सब, जादू समाप्त हो गया, यदि कोई हो। अब मैं इस इनिशलाइज़र को एक परीक्षण संदर्भ में पंजीकृत करूँगा:

 @DataJpaTest @ContextConfiguration(initializers = EmbeddedPostgresInitializer.class) ...

या सुविधा के लिए भी, आप अपना स्वयं का एनोटेशन बना सकते हैं, क्योंकि हम सभी एनोटेशन से प्यार करते हैं!

 @Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) @DataJpaTest @ContextConfiguration(initializers = EmbeddedPostgresInitializer.class) public @interface EmbeddedPostgresTest { }

अब @EmbeddedPostgrestTest द्वारा @EmbeddedPostgrestTest किया गया कोई भी परीक्षण डेटाबेस को एक यादृच्छिक पोर्ट पर शुरू करेगा और एक यादृच्छिक नाम के साथ, स्प्रिंग को इस डेटाबेस से कनेक्ट करने के लिए कॉन्फ़िगर करेगा और परीक्षण के अंत में इसे रोक देगा।

 @EmbeddedPostgresTest class JpaCakeFinderTestWithEmbeddedPostgres { ... }

निष्कर्ष

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

श्रृंखला के अन्य लेखों के लिंक

स्प्रिंग बूट पर टीडीडी अनुप्रयोग: परीक्षणों को ठीक-ठीक करना और संदर्भ के साथ काम करना