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

मैं सामान्य तौर पर TDD और परीक्षण के बारे में ज्यादा बात नहीं करता, मैं हर किसी को पहला लेख पढ़ने के लिए आमंत्रित करता हूं - ट्रंक में पिरामिड का निर्माण कैसे करें या स्प्रिंग बूट / geek पत्रिका पर अनुप्रयोगों के परीक्षण-चालित विकास

मैं पिछली बार की तरह, एक छोटे से सैद्धांतिक भाग के साथ शुरू करूंगा, और अंत-से-अंत परीक्षण पर आगे बढ़ूंगा।

परीक्षण पिरामिड

परीक्षण पिरामिड या परीक्षण पिरामिड के रूप में परीक्षण में इस तरह के एक महत्वपूर्ण इकाई का एक छोटा लेकिन आवश्यक विवरण के साथ शुरू करने के लिए।

( द प्रैक्टिकल टेस्ट पिरामिड से लिया गया)

परीक्षण पिरामिड कई स्तरों पर परीक्षण आयोजित किए जाने पर दृष्टिकोण है।

• UI (या एंड-टू-एंड, E2E ) परीक्षण कुछ कम हैं और वे धीमे हैं, लेकिन वे असली एप्लिकेशन का परीक्षण करते हैं - कोई नकली और परीक्षण समकक्ष नहीं। व्यवसाय अक्सर इस स्तर पर सोचते हैं और सभी BDD चौखटे यहाँ रहते हैं (पिछले लेख में ककड़ी देखें)।
• उनके बाद एकीकरण परीक्षण (सेवा, घटक - प्रत्येक की अपनी शब्दावली) होती है, जो पहले से ही सिस्टम के एक विशिष्ट घटक (सेवा) पर ध्यान केंद्रित करती है, इसे अन्य घटकों से मोकी / डबल्स के माध्यम से अलग करती है, लेकिन फिर भी वास्तविक बाहरी प्रणालियों के साथ एकीकरण की जांच कर रही है - ये परीक्षण जुड़े हुए हैं डेटाबेस में, REST अनुरोध भेजें, मैं एक संदेश कतार के साथ काम करता हूं। वास्तव में, ये परीक्षण हैं जो बाहरी दुनिया के साथ व्यापार तर्क के एकीकरण को सत्यापित करते हैं।
• बहुत नीचे त्वरित इकाई परीक्षण होते हैं जो कोड के न्यूनतम ब्लॉकों (वर्गों, विधियों) का पूर्ण अलगाव में परीक्षण करते हैं।

स्प्रिंग प्रत्येक स्तर के लिए परीक्षण लिखने में मदद करता है - यहां तक ​​कि इकाई परीक्षणों के लिए भी , हालांकि यह अजीब लग सकता है, क्योंकि इकाई परीक्षणों की दुनिया में फ्रेमवर्क के बारे में कोई भी ज्ञान बिल्कुल भी मौजूद नहीं होना चाहिए। E2E टेस्ट लिखने के बाद, मैं सिर्फ यह दिखाऊंगा कि कैसे स्प्रिंग इस तरह के विशुद्ध रूप से "एकीकरण" को नियंत्रित करने के लिए नियंत्रकों जैसी चीजों की अनुमति देता है।

लेकिन मैं पिरामिड के बहुत ऊपर से शुरू करूंगा - धीमा यूआई परीक्षण, जो एक पूर्ण अनुप्रयोग शुरू और परीक्षण करता है।

एंड-टू-एंड टेस्ट

तो, एक नई सुविधा:

Feature: A list of available cakes Background: catalogue is updated Given the following items are promoted | Title | Price | | Red Velvet | 3.95 | | Victoria Sponge | 5.50 | Scenario: a user visiting the web-site sees the list of items Given a new user, Alice When she visits Cake Factory web-site Then she sees that "Red Velvet" is available with price £3.95 And she sees that "Victoria Sponge" is available with price £5.50 

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

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

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

इसलिए, जेपीए समर्थन जोड़ने के लिए, मैंने कुछ निर्भरताएं जोड़ीं:

 implementation('org.springframework.boot:spring-boot-starter-data-jpa') runtime('com.h2database:h2') 

एक डेटाबेस के रूप में मैं H2 का उपयोग करूंगा - जावा में लिखा एक एम्बेडेड डेटाबेस, इन-मेमोरी मोड में काम करने की क्षमता के साथ।

स्प्रिंग डेटा JPA का उपयोग करते हुए, मैं तुरंत डेटा तक पहुँचने के लिए एक इंटरफ़ेस परिभाषित करता हूं:

 interface CakeRepository extends CrudRepository<CakeEntity, String> { } 

और सार:

 @Entity @Builder @AllArgsConstructor @Table(name = "cakes") class CakeEntity { public CakeEntity() { } @Id @GeneratedValue(strategy = GenerationType.IDENTITY) Long id; @NotBlank String title; @Positive BigDecimal price; @NotBlank @NaturalId String sku; boolean promoted; @Override public boolean equals(Object o) { if (this == o) return true; if (o == null || getClass() != o.getClass()) return false; CakeEntity cakeEntity = (CakeEntity) o; return Objects.equals(title, cakeEntity.title); } @Override public int hashCode() { return Objects.hash(title); } } 

इकाई के विवरण में कुछ स्पष्ट बातें हैं।

• @NaturalId sku फील्ड के लिए @NaturalId । इस क्षेत्र का उपयोग संस्थाओं की समानता की जांच के लिए "प्राकृतिक पहचानकर्ता" के रूप में किया जाता है - सभी क्षेत्रों या @Id फ़ील्ड का equals / @Id विधियों में उपयोग करना बल्कि एक विरोधी पैटर्न है। यह अच्छी तरह से लिखा है कि संस्थाओं की समानता को सही ढंग से कैसे सत्यापित किया जाए, उदाहरण के लिए, यहां ।
• बॉयलरप्लेट कोड को थोड़ा कम करने के लिए, मैं जावा के लिए प्रोजेक्ट लोम्बोक - एनोटेशन प्रोसेसर का उपयोग करता हूं। यह आपको विभिन्न उपयोगी चीजों को जोड़ने की अनुमति देता है, जैसे @Builder - स्वचालित रूप से सभी क्षेत्रों के लिए एक निर्माता बनाने के लिए एक वर्ग और @AllArgsConstructor लिए एक बिल्डर उत्पन्न करने के लिए।

स्प्रिंग डेटा द्वारा स्वचालित रूप से एक इंटरफ़ेस कार्यान्वयन प्रदान किया जाएगा।

पिरामिड के नीचे

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

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

 @ExtendWith(MockitoExtension.class) class IndexControllerTest { @Mock CakeFinder cakeFinder; @InjectMocks IndexController indexController; private Set<Cake> cakes = Set.of(new Cake("Test 1", "£10"), new Cake("Test 2", "£10")); @BeforeEach void setUp() { when(cakeFinder.findPromotedCakes()).thenReturn(cakes); } @Test void shouldReturnAListOfFoundPromotedCakes() { ModelAndView index = indexController.index(); assertThat(index.getModel()).extracting("cakes").contains(cakes); } } 

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

मैं मॉकिटो के बारे में ज्यादा बात नहीं करूंगा, आप आधिकारिक दस्तावेज में सब कुछ पढ़ सकते हैं। विशेष रूप से, इस परीक्षण में केवल दिलचस्प बिंदु हैं - मैं परीक्षण MockitoExtension.class रूप में MockitoExtension.class उपयोग करता MockitoExtension.class , और यह स्वचालित रूप से @Mock द्वारा एनोटेट किए गए फ़ील्ड के लिए मोक उत्पन्न करेगा और फिर इन @ मोक के रूप में चिह्नित @InjectMocks गए फ़ील्ड में ऑब्जेक्ट के लिए निर्माता के रूप में इन मोक को इंजेक्ट @InjectMocks । आप यह सब मैन्युअल रूप से Mockito.mock() विधि का उपयोग करके कर सकते हैं और फिर एक वर्ग बना सकते हैं।

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

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

@DataJpaTest का उपयोग करके जेपीए के लिए एकीकरण परीक्षण

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

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

• @AutoConfigureDataJpa
• @AutoConfigureTestDatabase
• @AutoConfigureCache
• @AutoConfigureTestEntityManager
• @Transactional

पहले मैं आपको व्यक्तिगत रूप से प्रत्येक के बारे में बताऊंगा, और फिर मैं आपको तैयार परीक्षण दिखाऊंगा।

@AutoConfigureDataJpa
यह कॉन्फ़िगरेशन का एक पूरा सेट लोड करता है और रिपॉजिटरी ( CrudRepositories लिए कार्यान्वयन की स्वचालित पीढ़ी), फ्लाईवे और लिक्विबेस डेटाबेस के लिए माइग्रेशन टूल, डेटासोर्स, लेनदेन प्रबंधक और अंततः हाइबरनेट का उपयोग करके डेटाबेस से कनेक्ट करता है। वास्तव में, यह डेटा तक पहुंचने के लिए प्रासंगिक कॉन्फ़िगरेशन का एक सेट है - न तो वेब एमवीसी से DispatcherServlet , न ही अन्य घटकों को यहां शामिल किया गया है।

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

यह याद रखने योग्य है कि यह आधार पूरी तरह से खाली होगा, बिना किसी योजना के। सर्किट उत्पन्न करने के लिए, कुछ विकल्प हैं।

1. हाइबरनेट से ऑटो डीडीएल सुविधा का उपयोग करें। स्प्रिंग बूट टेस्ट स्वचालित रूप से यह मान सेट create-drop करने के create-drop सेट करेगा ताकि हाइबरनेट इकाई विवरण से एक स्कीमा उत्पन्न करेगा और सत्र के अंत में इसे हटा देगा। यह हाइबरनेट की एक अविश्वसनीय रूप से शक्तिशाली विशेषता है, जो परीक्षणों के लिए बहुत उपयोगी है।
2. फ्लाईवे या लिक्विबेस द्वारा निर्मित माइग्रेशन का उपयोग करें।

आप दस्तावेज़ में डेटाबेस को इनिशियलाइज़ करने के विभिन्न तरीकों के बारे में अधिक पढ़ सकते हैं।

@AutoConfigureCache
यह सिर्फ कैश को NoOpCacheManager का उपयोग करने के लिए कॉन्फ़िगर करता है - अर्थात कुछ भी कैश न करें। परीक्षणों में आश्चर्य से बचने के लिए यह उपयोगी है।

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

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

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

@SpringBootTest के साथ एकीकरण टेस्ट

मैं यह भी नोट करना चाहता हूं कि @DataJpaTest फोकल इंटीग्रेशन टेस्ट का एक अनूठा उदाहरण नहीं है, यहाँ @WebMvcTest , @DataMongoTest और कई अन्य हैं। लेकिन सबसे महत्वपूर्ण परीक्षण एनोटेशन में से एक @SpringBootTest बना @SpringBootTest , जो सभी कॉन्फ़िगर किए गए घटकों और इंटीग्रेशन के साथ एप्लिकेशन को "जैसा है" लॉन्च करता है। एक तार्किक प्रश्न उठता है - यदि आप पूरे एप्लिकेशन को चला सकते हैं, तो उदाहरण के लिए फोकल डाटाजापा परीक्षण क्यों करते हैं? मैं कहूंगा कि यहां फिर से कोई सख्त नियम नहीं हैं।

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

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

परीक्षण के लिए डेटा तैयार करना

परीक्षण के लिए मुख्य बिंदुओं में से एक डेटा तैयारी है। प्रत्येक परीक्षण को अलग-थलग किया जाना चाहिए, और शुरू करने से पहले पर्यावरण को तैयार करना चाहिए, सिस्टम को इसकी मूल वांछित स्थिति में लाना चाहिए। ऐसा करने के लिए सबसे आसान विकल्प @BeforeEach / @BeforeAll एनोटेशन का उपयोग करना और रिपॉजिटरी, TestEntityManager या TestEntityManager का उपयोग करके डेटाबेस में प्रविष्टियां जोड़ना है। लेकिन एक और विकल्प है जो आपको तैयार स्क्रिप्ट को चलाने या वांछित SQL क्वेरी को निष्पादित करने की अनुमति देता है, यह @Sql एनोटेशन है। परीक्षण चलाने से पहले, स्प्रिंग बूट टेस्ट स्वचालित रूप से निर्दिष्ट स्क्रिप्ट को @BeforeAll , @BeforeAll ब्लॉक को जोड़ने की आवश्यकता को समाप्त कर देगा, और @BeforeAll डेटा की @Transactional का ध्यान रखेगा।

 @DataJpaTest class JpaCakeFinderTest { private static final String PROMOTED_CAKE = "Red Velvet"; private static final String NON_PROMOTED_CAKE = "Victoria Sponge"; private CakeFinder finder; @Autowired CakeRepository cakeRepository; @Autowired TestEntityManager testEntityManager; @BeforeEach void setUp() { this.testEntityManager.persistAndFlush(CakeEntity.builder().title(PROMOTED_CAKE) .sku("SKU1").price(BigDecimal.TEN).promoted(true).build()); this.testEntityManager.persistAndFlush(CakeEntity.builder().sku("SKU2") .title(NON_PROMOTED_CAKE).price(BigDecimal.ONE).promoted(false).build()); finder = new JpaCakeFinder(cakeRepository); } ... } 

लाल-हरा-परावर्तक चक्र

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

डेटा की तैयारी

मैं @BeforeAll / @BeforeEach साथ दृष्टिकोण का उपयोग करता @BeforeEach और मैन्युअल रूप से डेटाबेस में सभी रिकॉर्ड बनाता @BeforeEach । @Sql एनोटेशन के साथ उदाहरण को एक अलग वर्ग JpaCakeFinderTestWithScriptSetup में ले जाया गया है, यह परीक्षणों को डुप्लिकेट करता है, जो निश्चित रूप से नहीं होना चाहिए, और दृष्टिकोण का प्रदर्शन करने के एकमात्र उद्देश्य के लिए मौजूद है।

सिस्टम की प्रारंभिक स्थिति - सिस्टम में दो प्रविष्टियां हैं, एक केक प्रचार में भाग लेता है और विधि द्वारा वापस किए गए परिणाम में शामिल होना चाहिए, दूसरा - नहीं।

पहला परीक्षण एकीकरण परीक्षण

पहला परीक्षण सबसे सरल है - findPromotedCakes को प्रचार में भाग लेने वाले केक का विवरण और मूल्य शामिल होना चाहिए।

लाल

  @Test void shouldReturnPromotedCakes() { Iterable<Cake> promotedCakes = finder.findPromotedCakes(); assertThat(promotedCakes).extracting(Cake::getTitle).contains(PROMOTED_CAKE); assertThat(promotedCakes).extracting(Cake::getPrice).contains("£10.00"); } 

परीक्षण, ज़ाहिर है, क्रैश - डिफ़ॉल्ट कार्यान्वयन एक खाली सेट देता है।

ग्रीन

स्वाभाविक रूप से, हम तुरंत फ़िल्टरिंग लिखना चाहेंगे, where और इसी तरह से डेटाबेस के लिए एक अनुरोध करें। लेकिन टीडीडी अभ्यास के बाद, मुझे परीक्षा पास करने के लिए न्यूनतम कोड लिखना होगा । और यह न्यूनतम कोड डेटाबेस में सभी रिकॉर्ड वापस करना है। हां, इतना सरल और कॉर्नी।

  public Set<Cake> findPromotedCakes() { Spliterator<CakeEntity> cakes = this.cakeRepository.findAll() .spliterator(); return StreamSupport.stream(cakes, false).map( cakeEntity -> new Cake(cakeEntity.title, formatPrice(cakeEntity.price))) .collect(Collectors.toSet()); } private String formatPrice(BigDecimal price) { return "£" + price.setScale(2, RoundingMode.DOWN).toPlainString(); } 

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

Refactor

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

दूसरा परीक्षण

लेकिन दूसरा परीक्षण पहले से ही सत्यापित करेगा कि कोई भी प्रोमोटेड केक findPromotedCakes द्वारा लौटाए गए परिणाम में नहीं findPromotedCakes ।

  @Test void shouldNotReturnNonPromotedCakes() { Iterable<Cake> promotedCakes = finder.findPromotedCakes(); assertThat(promotedCakes).extracting(Cake::getTitle) .doesNotContain(NON_PROMOTED_CAKE); } 

लाल

परीक्षण, जैसा कि अपेक्षित था, क्रैश होता है - डेटाबेस में दो रिकॉर्ड होते हैं और कोड बस उन सभी को वापस करता है।

ग्रीन

और फिर से आप सोच सकते हैं - और न्यूनतम कोड क्या है जिसे आप टेस्ट पास करने के लिए लिख सकते हैं? चूंकि पहले से ही एक धारा और इसकी विधानसभा है, आप बस वहां एक filter ब्लॉक जोड़ सकते हैं।

  public Set<Cake> findPromotedCakes() { Spliterator<CakeEntity> cakes = this.cakeRepository.findAll() .spliterator(); return StreamSupport.stream(cakes, false) .filter(cakeEntity -> cakeEntity.promoted) .map(cakeEntity -> new Cake(cakeEntity.title, formatPrice(cakeEntity.price))) .collect(Collectors.toSet()); } 

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

Refactor

और चूंकि सभी परीक्षण हरे हैं - यह रिफ्लेक्टर का समय है। मुझे लगता है कि यह स्पष्ट करने की कोई आवश्यकता नहीं है कि स्मृति में फ़िल्टरिंग एक अच्छा विचार नहीं है, डेटाबेस में ऐसा करना बेहतर है। ऐसा करने के लिए, मैंने CakesRepository में एक नई विधि CakesRepository - findByPromotedIsTrue :

 interface CakeRepository extends CrudRepository<CakeEntity, String> { Iterable<CakeEntity> findByPromotedIsTrue(); } 

इस विधि के लिए, स्प्रिंग डेटा ने स्वचालित रूप से एक विधि उत्पन्न की, जो कि select from cakes where promoted = true गए फॉर्म की एक क्वेरी निष्पादित करेगी, select from cakes where promoted = true । स्प्रिंग डेटा प्रलेखन में क्वेरी पीढ़ी के बारे में और पढ़ें।

  public Set<Cake> findPromotedCakes() { Spliterator<CakeEntity> cakes = this.cakeRepository.findByPromotedIsTrue() .spliterator(); return StreamSupport.stream(cakes, false).map( cakeEntity -> new Cake(cakeEntity.title, formatPrice(cakeEntity.price))) .collect(Collectors.toSet()); } 

यह लचीलापन का एक अच्छा उदाहरण है जो एकीकरण परीक्षण और ब्लैक बॉक्स दृष्टिकोण प्रदान करता है। यदि भंडार को बंद कर दिया गया था, तो परीक्षणों को बदलने के बिना एक नई विधि जोड़ना असंभव नहीं था।

उत्पादन आधार से कनेक्शन

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

सब कुछ पारंपरिक रूप से application.yml में अनुभाग द्वारा जोड़ा जाता है:

 datasource: url: jdbc:h2:./data/cake-factory 

यह स्वचालित रूप से ./data फ़ोल्डर में फ़ाइल सिस्टम में डेटा को ./data । मैं ध्यान देता हूं कि यह फ़ोल्डर परीक्षणों में नहीं बनाया जाएगा - @DataJpaTest @AutoConfigureTestDatabase एनोटेशन की उपस्थिति के कारण मेमोरी में एक यादृच्छिक डेटाबेस के साथ फ़ाइल डेटाबेस के कनेक्शन को स्वचालित रूप से बदल देगा।

, — data.sql schema.sql . , Spring Boot . , , , .

निष्कर्ष

, , , TDD .

Spring Security — Spring, .