मुझे विशेष रूप से निम्नलिखित परिदृश्य में रूचि है। मान लें कि आपके पास ऐसी टीम है जो उत्पादन कोड लिखती है और एक टीम जो स्वचालित परीक्षण लिखती है। स्वचालित परीक्षण लिखने वाली टीम में स्वचालित परीक्षण लिखने के लिए एक समर्पित ढांचा होता है। क्या परीक्षण टीम अपने ढांचे के लिए इकाई परीक्षण लिखनी चाहिए हालांकि ढांचे का उत्पादन में उपयोग नहीं किया जाता है?क्या आप गैर उत्पादन कोड के लिए यूनिट परीक्षण करते हैं?
मैं उस स्थिति में किया गया है और क्या मैंने किया भी परीक्षण ढांचे के लिए एक परीक्षण सुइट के रूप में उत्पादन कोड के लिए टेस्ट स्वीट का उपयोग करें । संभवतः, ढांचे की सभी विशेषताओं का वास्तव में उपयोग किया जाता था, इसलिए अगर उत्पादन कोड में बदलाव किए बिना परीक्षण विफल रहे, तो परीक्षण ढांचे में एक समस्या होनी चाहिए।
यह ठीक-आईश काम करता है - एक परीक्षण परीक्षण-परीक्षण करने की तुलना में उन परीक्षणों को बहुत अधिक समय लगता है, और कभी-कभी मैं उन सभी को नहीं चलाऊंगा और उत्पादन निर्माण सर्वर पर कोई समस्या नहीं आती। ऐसी समस्याओं का निदान करने से टेस्ट-टेस्टाइट के साथ अधिक समय लगेगा।
सब कुछ, मैंने कभी इसके साथ सहज महसूस नहीं किया और वास्तव में परीक्षण ढांचे के लिए समर्पित परीक्षण करने की भी सिफारिश की जाएगी। परीक्षण-लेखन टीम के दृष्टिकोण से, परीक्षण ढांचे उत्पादन कोड है। और यदि परीक्षण ढांचे का उपयोग किसी और द्वारा किया जाता है, जिसका परीक्षण सूट आपको तक पहुंच नहीं है ...
हां, अगर केवल यह जांचने के लिए कि ढांचा पर्याप्त परीक्षण कवरेज उत्पन्न करता है।
नरक हाँ!
टीडीडी आपको विकास में बढ़त देता है, यह सिर्फ ग्राहक को खुश करने के लिए नहीं है। यह आपको टेस्टेबल, पुन: प्रयोज्य और मॉड्यूलर कोड लिखने की अनुमति देता है। मैं इकाई को जो कुछ भी काम करना है, उसका परीक्षण करेगा, खासकर यदि आप इसे अक्सर बदलना चाहते हैं (नई सुविधाओं को जोड़ने के लिए रिफैक्टर)।
परीक्षण टीम को जो कुछ भी करना चाहिए जो उनके ढांचे द्वारा दिए गए परिणामों में अपना विश्वास बढ़ा सकता है।
यह परीक्षण, कोड समीक्षाएँ, गुणवत्ता मानकों, शामिल हैं ...
यह प्रश्न मुझे एक कहानी की याद दिलाता है: एक बार एक समय पर एक कंपनी थी। यह कंपनी स्वचालित परीक्षणों में विश्वास करती है। यह विश्वास इतना मजबूत है कि यह एक समूह बनाने का कारण बनता है जिसका एकमात्र उद्देश्य इन स्वचालित परीक्षणों को लिख रहा है। सभी सबसे उत्साही विश्वासियों को इस समूह में शामिल होने की अनुमति है। बहुत खुशी हुई!
फिर एक दिन, यह पता चला है कि यह स्वचालित परीक्षण समूह, अपने मिशन के बावजूद, अपने स्वयं के काम के लिए स्वचालित परीक्षण का उपयोग नहीं करता है। पत्थर डाले जाते हैं, यादा यादा।
मैं बस इतना कह रहा हूं ... मुझे लगता है कि किसी भी परीक्षण ढांचे में ठोस ठोस कवरेज होगा।
आप इस तरह से मेरे प्रश्न देख सकते हैं। लेकिन मुझे लगता है कि इस तर्क के आधार पर गैर उत्पादन कोड का परीक्षण करने का फैसला करना मूर्खतापूर्ण है। परीक्षणों को बनाए रखना अंत में पैसे खर्च करता है और व्यक्तिगत रूप से मुझे लगता है कि आपको केवल स्वचालन ढांचे का परीक्षण करना चाहिए और स्वचालन प्रयोगशाला के हर हिस्से का परीक्षण नहीं करना चाहिए। दूसरी ओर, उत्पादन कोड में आपका लक्ष्य जितना संभव हो उतना परीक्षण करना है। यह मेरे प्रश्न का कारण है। – Ikaso
मुझे फ्लिप किया जा रहा है, लेकिन मेरा मुद्दा यह है कि वही मूल्यांकन मानदंड लागू किया जा सकता है। हम स्वचालित परीक्षण क्यों लिखते हैं, भले ही वे विकास की लागत में 15% जोड़ सकते हैं? अंत में, उत्तर है क्योंकि यह code_ में हमारा विश्वास बढ़ाता है। यह काला और सफ़ेद नहीं है - सवाल यह है कि हम 1 और परीक्षा लिखना चाहिए?अगर हमें पहले से ही कोड में विश्वास है, या आत्मविश्वास होना महत्वपूर्ण नहीं है, तो परीक्षण लिखने की कोई आवश्यकता नहीं है। मैं उस दिशानिर्देश को लागू करता हूं कि सॉफ्टवेयर का उपभोक्ता एक वाणिज्यिक ग्राहक, साथी डेवलपर या मेरा छोटा भाई है। – ndp