2008-10-16 6 views
27

कोडिंग परीक्षण पहले, मुझे लगता है कि शायद मेरे कोड का 3/4 यूनिट परीक्षण है; अगर मैं वास्तव में चरम था, और असफल इकाई परीक्षण को ठीक करने के अलावा कोड की एक पंक्ति नहीं लिखी, तो यह अनुपात भी अधिक होगा। इन सभी यूनिट परीक्षणों को बनाए रखना कोड परिवर्तनों में भारी मात्रा में जड़ता जोड़ता है। प्रारंभ में, मैं इसे चूसना और उन्हें ठीक करना। जैसे ही दबाव होता है, मैं '0 समय होने पर' फिर से देखने के लिए निर्देशिका के साथ समाप्त होता हूं। ऐसा लगता है कि डिजाइन में क्रिस्टलाइज करने का समय होने से पहले टीडीडी बहुत जल्द कवरेज कर रहा है।इकाई परीक्षणों के रखरखाव बोझ का प्रबंधन

मैं इस दुविधा से अपना रास्ता कैसे ढूंढूं, और बदलती आवश्यकताओं का स्वागत करना शुरू करता हूं जैसे कि मुझे लगता है?

+2

यह वास्तव में एक अच्छा सवाल है; जब आप कुछ कोड बदलते हैं तो यह दर्द होता है और फिर आपको मिलान करने के लिए सभी परीक्षणों को ठीक करना होगा, –

उत्तर

1

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

आम तौर पर मैं वैसे भी टीडीडी का वकील नहीं हूं। :)

3

यूनिट परीक्षण काफी अपरिवर्तनीय होना चाहिए।

यदि आप परीक्षा लिख ​​रहे हैं, तो परीक्षा उत्तीर्ण करने के लिए कोड लिखना और अपने अन्य परीक्षणों को तोड़ना, तो आपका नया कोड "गलत" माना जाना चाहिए।

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

+0

यूनिट टेस्ट वास्तव में उत्पाद की जीवन चक्र में विशेष रूप से अपरिवर्तनीय नहीं हैं और वे दर्पण की आवश्यकताओं और कोड के रूप में बदल सकते हैं वे खिलाफ परीक्षण करते हैं। –

8

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

यदि आपको लगता है कि यह एक ओवरहेड है तो बस उस समय के बारे में सोचें जब आप भविष्य में बगफिक्सिंग पर सहेज लेंगे।

इसके अलावा आप छोटे चक्रों में काम करने की कोशिश कर सकते हैं। अर्थात।

  1. के बजाय परिवर्तन का एक बहुत
  2. फिक्स इकाई का एक बहुत परीक्षण
  3. दोहराएँ

प्रयास करें

  1. एक छोटा सा परिवर्तन
  2. बदलें प्रासंगिक इकाई योजना बना रहे हैं परीक्षण (0)
  3. बदले प्रासंगिक कोड
  4. दोहराएँ

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

1

आपका परीक्षण शायद पर्याप्त केंद्रित नहीं है, या आपके सिस्टम में बहुत अधिक निर्भरताएं हैं।

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

सुनिश्चित नहीं हैं कि यह 100% स्पष्ट है ...

10

अलग प्रोग्रामर अनुशासन के पहलू रखते हुए ... (यह एक व्यक्तिगत बात एक साथी का निर्माण कर के बिना या सभी फिक्सिंग के बिना अगर आप चेक-इन करने के साथ ठीक हो परीक्षण। Agile उच्च अनुशासन मानता है .. और साहस & दबाव के तहत सही रास्ते पर रहने के लिए समर्थन :),

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

+0

"फ्रैगिल टेस्ट" वह शब्द है जिसे मैं ढूंढ रहा था। यहाँ, एक कुकी है! –