मेरे पास एक स्प्रिंग बूट एप्लिकेशन है जिसमें निम्नलिखित application.properties हैं:

spring.datasource.driver-class-name=oracle.jdbc.driver.OracleDriver
spring.datasource.url=jdbc:oracle:thin:@ldap:something
spring.datasource.username=${USERNAME}
spring.datasource.password=${PASSWORD}

जैसा कि आप देख सकते हैं, यह कुछ पर्यावरणीय चर पर निर्भर करता है। मेरा अंतिम गंतव्य docker image है लेकिन इससे पहले मैं gradle build कार्य चलाता हूं - और यह निश्चित रूप से विफल हो जाता है, क्योंकि यह पर्यावरणीय चर में USERNAME और PASSWORD नहीं ढूंढ सकता है।

इसलिए, मैं अपने प्रश्न को दो भागों में विभाजित करना चाहूंगा:

  1. क्या gradle test कार्य, जिसे gradle build के साथ निष्पादित किया गया है, डेटाबेस कनेक्शन का परीक्षण करने का प्रयास कर रहा है? यह डिफ़ॉल्ट रूप से करता है जब यह स्प्रिंग बूट एप्लिकेशन को बूटस्ट्रैप करने का प्रयास करता है - यही कारण है कि मेरा gradle build कार्य विफल हो जाता है। किसी भी तरह मुझे लगता है कि यह सबसे अच्छा विकल्प नहीं है - क्योंकि यूनिट परीक्षण मेरी राय में डेटाबेस कनेक्शन जैसे किसी बाहरी कारक पर निर्भर नहीं होना चाहिए।

  2. क्या पहले gradle build को चलाना और फिर docker build को चलाना एक अच्छा विचार है? या सब कुछ एक ही बार में किया जाना चाहिए? तब मैं कम से कम docker run पर पर्यावरण चर परिभाषित कर सकता हूं। लेकिन फिर, मैं यह जाने बिना कि बिल्ड ठीक है और सभी परीक्षण पास हो गए हैं, मैं डॉकर छवि नहीं बनाना चाहता।

1
pkey 11 सितंबर 2018, 11:07

3 जवाब

सबसे बढ़िया उत्तर

"क्या यह एक अच्छा विचार है" वाले प्रश्नों का उत्तर देना कठिन है, लेकिन मैं कोशिश करूँगा...

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

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

1
Neville Kuyt 11 सितंबर 2018, 11:30

आपके सवालों के जवाब:

  1. मेरी विनम्र राय में, सामान्य तौर पर, gradle test को gradle build के बाद निष्पादित किया जाना चाहिए। जब तक आपका डेटाबेस परीक्षण परीक्षणों में से एक नहीं है, यदि आप इसका उपयोग केवल अपने परीक्षणों के लिए जानकारी एकत्र करने के लिए करते हैं, तो मैं डेटाबेस जांच के बाद gradle test निष्पादित करूंगा।
  2. हाँ, यह करना एक अच्छा विचार है:
    • सबसे पहले, docker build
    • दूसरा, docker run -e USERNAME=XXXX -e PASSWORD=XXXX...
    • तीसरा, gradle build docker के अंदर।
1
mulg0r 11 सितंबर 2018, 11:13

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

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

ऐसा करने के लिए, आप एक परीक्षण निर्भरता के रूप में अपने प्रोजेक्ट में एचएसक्यूएलडीबी जैसे इन-मेमोरी डेटाबेस जोड़ सकते हैं:

testCompile("org.hsqldb:hsqldb")

उसके बाद, आप एक अलग application-test.properties फ़ाइल प्रदान कर सकते हैं:

spring.datasource.url=jdbc:hsqldb:mem
spring.datasource.username=user
spring.datasource.password=pass

अब आप किसी भी परीक्षण की व्याख्या कर सकते हैं जिसके लिए @ActiveProfiles("test") के साथ डेटाबेस कनेक्शन की आवश्यकता है।

भले ही आपको परीक्षण उद्देश्यों के लिए इन-मेमोरी डेटाबेस पसंद नहीं है, फिर भी आप अपने परीक्षण के लिए एक अलग डेटाबेस कॉन्फ़िगरेशन का उपयोग करने के लिए एकाधिक प्रोफाइल का उपयोग करने के दृष्टिकोण का उपयोग कर सकते हैं (उदाहरण के लिए एक हार्डकोडेड कनेक्शन + डेटाबेस के लिए उपयोगकर्ता नाम/पासवर्ड)।

1
g00glen00b 11 सितंबर 2018, 15:37