2008-11-11 26 views
35

के साथ यूनिट परीक्षण बनाम एकीकरण परीक्षण मैं स्प्रिंग एमवीसी प्रोजेक्ट पर काम कर रहा हूं, और मेरे पास स्रोत पेड़ के सभी विभिन्न घटकों के लिए यूनिट परीक्षण हैं।स्प्रिंग

उदाहरण के लिए, अगर मैं एक नियंत्रक HomeController है, जो एक LoginService यह में इंजेक्शन की जरूरत है, तो मेरी इकाई परीक्षण HomeControllerTest में मैं बस के रूप में सामान्य वस्तु (वसंत के बाहर) का दृष्टांत और संपत्ति इंजेक्षन:

protected void setUp() throws Exception { 
    super.setUp(); 
    //... 
    controller = new HomeController(); 
    controller.setLoginService(new SimpleLoginService()); 
    //... 
} 

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

  1. यह मेरा पहला स्प्रिंग परियोजना है:

    तो, यहाँ मेरी सवाल कर रहे हैं (एकीकरण परीक्षण) परीक्षण करने के लिए कि वास्तविक अनुप्रयोग संदर्भ के साथ सब कुछ अपेक्षित काम करता है? क्या इसके लिए एक स्थापित सर्वोत्तम अभ्यास है?

  2. इसके अतिरिक्त, आप इकाई परीक्षणों को एकीकरण परीक्षण से अलग कैसे करते हैं? मेरे पास src में सभी स्रोत कोड हैं, यूनिट परीक्षण test में - एकीकरण परीक्षण मामलों के लिए दूसरा परीक्षण फ़ोल्डर (जैसे test-integration) होना चाहिए? और नहीं बल्कि पहिया फिर से आविष्कार से मैं नहीं बल्कि समुदाय के बाकी पूछना -

चूंकि यह मेरी पहली वसंत परियोजना है, मैं उत्सुक दूसरों आमतौर पर बात की इस तरह करने के बारे में जाना कैसे कर रहा हूँ।

उत्तर

32

मैं सबसे अच्छा अभ्यास होने के लिए बात नहीं कर सकता, लेकिन यहां मैंने जो किया है वह मैंने पहले किया है।

ईकाई परीक्षण:

  • गैर तुच्छ सेम (यानी, अपने स्प्रिंग के सबसे संबंधित सेम) इंजेक्शन सेवाओं के लिए
  • उपयोग Mocks के लिए इकाई परीक्षण बनाएं जहां व्यावहारिक (यानी, सबसे सब नहीं तो समय)।
  • प्रोजेक्ट test निर्देशिका में इन परीक्षणों के लिए मानक नामकरण सम्मेलन का उपयोग करें। Test या TestCase का उपयोग कक्षा नाम के उपसर्ग या प्रत्यय के रूप में व्यापक रूप से प्रचलित प्रतीत होता है।

एकता टेस्ट:

  • एक AbstractIntegrationTestCase कि सेट बनाएँ SpringWebApplicationContext intetgration परीक्षण clases में इस्तेमाल के लिए।
  • test निर्देशिका में एकीकरण परीक्षण के लिए एक नामकरण सम्मेलन का उपयोग करें। मैंने इन परीक्षणों के लिए उपसर्ग या प्रत्यय के रूप में IntTest या IntegrationTest का उपयोग किया है।

सेट करें तीन चींटी test लक्ष्य:

  1. परीक्षण सब (या जो भी आप इसे नाम करना चाहते हैं): भागो यूनिट और एकता टेस्ट
  2. परीक्षण: भागो ईकाई परीक्षण (सिर्फ इसलिए test लगता है इकाई परीक्षण
  3. परीक्षण एकीकरण के लिए सबसे आम उपयोग होने के लिए:। के रूप में विख्यात एकीकरण परीक्षण चलाने

, आप नामकरण सम्मेलनों का उपयोग कर सकते हैं जो आपके प्रोजेक्ट के लिए समझ में आते हैं।

यूनिट को एकीकरण निर्देशिका से एक अलग निर्देशिका में अलग करने के लिए, मुझे नहीं लगता कि डेवलपर्स और उनके उपकरण उन्हें आसानी से ढूंढ और निष्पादित कर सकते हैं।

उदाहरण के तौर पर, आखिरी जावा प्रोजेक्ट मैंने स्प्रिंग के साथ काम किया जो कि ऊपर वर्णित है, एकीकरण परीक्षण और यूनिट परीक्षण उसी test निर्देशिका में रहने के साथ। दूसरी तरफ, Grails परियोजनाओं, एक सामान्य परीक्षण निर्देशिका के तहत स्पष्ट रूप से अलग इकाई और एकीकरण परीक्षण निर्देशिकाओं।

+1

यह एक अच्छी रणनीति की तरह लगता है। लेकिन एक ही निर्देशिका में यूनिट परीक्षण और एकीकरण परीक्षण के साथ, ग्रहण के लिए उन्हें अलग करने का कोई तरीका नहीं है, है ना? ग्रहण परीक्षण चलाने के लिए ग्रहण का एकमात्र विकल्प केवल एक को चलाने या किसी निश्चित फ़ोल्डर में चलाने के लिए है - उन्हें एंट जैसे नाम से विभाजित नहीं किया जा सकता है। –

+0

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

4

वसंत के साथ बहुत सी कठिन डबल-बुक-रखरखाव दूर हो जाती है यदि आप पूरी तरह से एनोटेटेड शासन पर भी जाते हैं, जहां आप अपने सभी बीन्स को @ कॉम्पोनेंट, @ कंट्रोलर, @ सेवा और @ रिपोजिटरी के साथ एनोटेट करते हैं। इंजेक्शन प्राप्त करने के लिए आपको आवश्यक विशेषताओं में @Autowired जोड़ें।

वसंत संदर्भ मैनुअल के अनुभाग 3.11 देखें। http://static.springframework.org/spring/docs/2.5.x/reference/beans.html#beans-annotation-config

संबंधित नोट पर, हम केनजी का वर्णन करने वाले विभाजन इकाई/इंटीग्रेट्रियन परीक्षणों का उपयोग कर रहे हैं। मेरे हालिया शासन में हमने परीक्षणों की एक तीसरी "कक्षा", "कंपोनेंटटेस्ट" भी पेश की है। ये पूर्ण वसंत तारों के साथ चलते हैं, लेकिन वायर्ड स्टब कार्यान्वयन के साथ (घटक-स्कैन फ़िल्टर और वसंत में एनोटेशन का उपयोग करके)।

कारण हमने ऐसा इसलिए किया क्योंकि कुछ "सेवा" परत के लिए आप बीन को मैन्युअल रूप से तारित करने के लिए हाथ से कोडित तारों के एक भयानक राशि के साथ समाप्त होते हैं, और कभी-कभी हास्यास्पद मात्रा में नकली-वस्तुएं भी बनाते हैं। परीक्षण की 5 लाइनों के लिए तारों की 100 लाइनें असामान्य नहीं हैं। घटक परीक्षण इस समस्या को कम करता है।

+0

दुर्भाग्य से मैं अभी भी जावा 1.4 का उपयोग कर रहा हूं :( –

0

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

2

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

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

0

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

6

कुछ अलग अंक:

हाँ, यह एक आम दृष्टिकोण परीक्षण वसंत के है - अलग इकाई परीक्षण और एकीकरण परीक्षणों जहां पूर्व किसी भी वसंत संदर्भ लोड नहीं करता है।

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

यदि आप परीक्षण निर्भरता के टन में वायरिंग कर रहे हैं तो वे वास्तव में यूनिट परीक्षण नहीं हैं। वे एकीकरण परीक्षण हैं जहां आप निर्भरता इंजेक्शन के बजाय नए का उपयोग कर निर्भरताओं की तारों को तारित कर रहे हैं। जब आपका उत्पादन अनुप्रयोग वसंत का उपयोग करता है तो समय और अपर्याप्त प्रयास की बर्बादी!

अपने वसंत संदर्भ लाने के लिए बुनियादी एकीकरण परीक्षण उपयोगी हैं।

@required एनोटेशन आपको यह सुनिश्चित करने में मदद कर सकता है कि आप अपने वसंत तारों में आवश्यक निर्भरताओं को पकड़ लें।

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

0

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