प्रति परत एकीकरण परीक्षण एक अच्छा अभ्यास है?

Question

मेरे पास एक ऐसा एप्लिकेशन है जो वसंत-एमवीसी का उपयोग करता है, मूल रूप से हमारे पास प्रेजेंटेशन लेयर (कंट्रोलर), सर्विस लेयर (बिजनेस यूनिट्स, हेल्पर्स), एकीकरण लेयर और डेटा एक्सेस लेयर (जेडीबीसी/जेपीए रिपोजिटरीज) है, हम परीक्षण का उपयोग करना सुनिश्चित करना चाहते हैं कोड के भविष्य में जो कुछ भी पहले काम कर रहा था उसे तोड़ नहीं देगा, ऐसा करने के लिए हम यूनिट परीक्षण (मॉकिटो) और एकीकरण परीक्षण (वसंत परीक्षण, वसंत-परीक्षण-एमवीसी) का उपयोग कर रहे हैं।

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

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

1. हम एक नियंत्रक है के रूप में, सेवा, डेटा परत एक दृष्टिकोण परत प्रति एक आईटी, उदाहरण हम UserService वर्ग है, हम UserServiceTest जो यूनिट टेस्ट और UserServiceIT हो जाएगा होगा किया जाता है, लेकिन रख-रखाव आदर्श नहीं है , मुझे लगता है कि कभी-कभी हम एक ही परीक्षण परिदृश्य को दोहराते हैं लेकिन अब वास्तविक प्रणाली का उपयोग करते हैं। क्या यह अभ्यास वास्तव में समझ में आता है या किस परिदृश्य में यह समझ में आता है? यदि यूनिट परीक्षण के साथ कक्षा में हमारे पास पहले से 100% परीक्षण कवरेज है, तो हमें इसके लिए आईटी की आवश्यकता क्यों है, ऐसा लगता है कि हमारे पास यह सुनिश्चित करने के लिए केवल वास्तविक घटक ही शुरू हो रहा है?, सभी समान परिदृश्यों को समझने के लिए समझें या कौन सा निर्णय लेने के लिए एक अच्छा मानदंड है?

2. अन्य दृष्टिकोण केवल एकीकरण परीक्षण के माध्यम से सबसे महत्वपूर्ण परीक्षण मामलों के साथ जाना है, लेकिन केवल नियंत्रक परत से, जिसका अर्थ है आरईएसटी सेवाओं का आह्वान करना और JSON आउटपुट को सत्यापित करना। यह पर्याप्त है?, हमें अन्य परतों में और चीजों को सत्यापित करने की आवश्यकता नहीं है? मुझे पता है कि वास्तविक रीस्ट एपीआई सभी परतों (नियंत्रक, सेवा, दाओ) के नीचे उपयोग करेगा लेकिन यह पर्याप्त है? कुछ विचार आप यहां कहेंगे?

3. यदि हमारे पास एक सहायक वर्ग है तो मुझे लगता है कि इकाई और आईटी रखने की भावना नहीं है, क्योंकि केवल एक उद्देश्य के लिए विधि के रूप में मुझे लगता है कि यूनिट परीक्षण यहां पर्याप्त होगा, क्या आपको ऐसा लगता है? ।

4. डेटा परत में कुछ कक्षाएं आईटी का उपयोग करने के लिए मानदंड API, QueryDSL का उपयोग कर सकती हैं क्योंकि कुछ मामलों में इकाई परीक्षण करना बेहद मुश्किल है, यह एक वैध औचित्य है?

मैं सबसे अच्छा तरीका है, टिप्स और प्रथाओं है कि प्रणाली अखंडता के मन में एक वास्तविक और मूल्यवान प्रक्रिया रखते हुए इस सामान के रख-रखाव सुनिश्चित करने का काम करता है पाने के लिए कोशिश कर रहा हूँ।

Answer 1

आप थोड़े अपने आवेदन के लिए आवश्यक संपूर्ण टेस्ट रणनीति को स्पर्श करते हैं। परीक्षण न केवल कवरेज और परतों के बारे में है। उदाहरण के रूप में:

हम परीक्षण का उपयोग कर कि कोड को भविष्य अलावा कुछ भी नहीं है कि पहले काम कर रहा था, यह हम इकाई परीक्षण (mockito) और एकीकरण परीक्षण (वसंत-परीक्षण का उपयोग कर रहे करने के लिए तोड़ने नहीं होगा सुनिश्चित करना चाहते हैं, वसंत-परीक्षण-MVC)।

इस प्रकार आप वास्तव में Regression testing का समर्थन करते हैं, जो एक प्रकार है। अगर हम (विस्तृत) टेस्ट पिरामिड

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

मैं इस एक

एकता परीक्षण पर आपसे सहमत अलग कहानी है और बहुत बहस का मुद्दा

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

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

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

नियंत्रक परत से, जिसका अर्थ है कि आरईएसटी सेवाओं का आह्वान करना और JSON आउटपुट सत्यापित करना। यह पर्याप्त है?, हमें अन्य परतों में और चीजों को सत्यापित करने की आवश्यकता नहीं है? मुझे पता है कि वास्तविक रीस्ट एपीआई सभी परतों (नियंत्रक, सेवा, दाओ) के नीचे उपयोग करेगा लेकिन यह पर्याप्त है?

बिल्कुल सही नहीं - प्रस्तुति परत का परीक्षण अंतर्निहित परतों का भी प्रयोग करेगा ... तो बाकी सभी परीक्षणों से परेशान क्यों हैं? यदि आप इस तरह के दृष्टिकोण के साथ ठीक हैं - सेलेनियम टीम ऐसे DB validation दृष्टिकोण का सुझाव देती है।

आप बात कर रहे हैं Beans के बारे में और ViewHelpers यहाँ

हम एक सहायक वर्ग मैं समझ बनाने इकाई और आईटी, के लिए नहीं लगता है कि राशि के रूप में के रूप में वहाँ विधि के सबसे केवल एक ही उद्देश्य के लिए मैं लगता है कि इकाई परीक्षण पर्याप्त होगा, क्या आप वही सोचते हैं?

आपको इकाई और आईटी दोनों की आवश्यकता होगी, क्योंकि सभी कारण अन्य घटकों के लिए मान्य हैं। Single responsibility होने से आईटी परीक्षण की आवश्यकता से इनकार नहीं किया जाता है।

कुछ मामलों में इकाई परीक्षण करना बेहद मुश्किल है, यह एक वैध औचित्य है?

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

Answer 2

दृष्टिकोण मैं सिफारिश करेंगे, स्प्रिंग आधारित codebases परीक्षण जावा ईई 7 के हाल के अनुभव के आधार पर, यह है:

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

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

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

Answer 3

यूनिट परीक्षण लागू होता है जैसा आपने कक्षाओं और घटकों पर किया था। इसका उद्देश्य है:

• कोड लिखें (टीडीडी)।
• कोड उपयोग को चित्रित करें और समय और परिवर्तन के साथ इसे टिकाऊ बनाएं।
• जितना संभव हो उतना सीमावर्ती मामलों को कवर करें।

जब आपको कुछ विशिष्ट उपयोग या पैरामीटर के साथ कोई समस्या आती है, तो पहले इसे एक नए परीक्षण के साथ पुन: उत्पन्न करें, फिर इसे ठीक करें।

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

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

आप "एकीकरण परत" को क्या कहते हैं?

प्रस्तुति परत परीक्षण कार्यात्मक परीक्षण की जिम्मेदारी है, न कि इकाई और न ही एकीकरण।

आपने प्रदर्शन परीक्षण के बारे में भी बात नहीं की।

अंत में, लक्ष्य परीक्षण के साथ-साथ नए परीक्षणों के साथ प्रजनन के बाद तय की गई बग, और सभी संभावित स्थितियों (ओएस, डेटाबेस, ब्राउज़र ...) में सभी प्रकार के परीक्षणों को संचयी करने के लिए अधिकतम कवरेज प्राप्त कर रहा है। तो आप अपनी समग्र परीक्षण गुणवत्ता को सत्यापित करते हैं:

• कवरेज की गणना करने वाला टूल। आपको कार्यात्मक परीक्षण से कवरेज का मूल्यांकन करने या उन्नत जेडीके उपकरणों का उपयोग करने के लिए कोड को मापना होगा।
• कुछ घटकों पर परीक्षण, सेवाओं की कमी से आने वाले कीड़े की संख्या ...

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

कवरेज भी एक महत्वपूर्ण बात नहीं है, लेकिन यदि आप अपनी गुणवत्ता पर ध्यान केंद्रित करते हैं तो कुछ कम परीक्षण करना बेहतर हो सकता है: थ्रेडसेफ, अनियंत्रित विधियों और कक्षाओं से बने, वास्तविक परिस्थितियों का परीक्षण (कोई परीक्षण स्थिति नहीं है " हैक्स)।

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