यूनिट परीक्षण एंटी-पैटर्न कैटलॉग

203

विरोधी पैटर्न : एक साधारण बुरी आदत, बुरे व्यवहार या बुरे विचार से वास्तविक विरोधी पैटर्न को औपचारिक रूप से अलग करने के लिए कम से कम दो प्रमुख तत्व मौजूद होने चाहिए:

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

टीडीडी विरोधी पैटर्न के लिए वोट करें जो आपने "जंगली में" एक बार बहुत अधिक देखा है।
जेम्स कैर द्वारा ब्लॉग पोस्ट और testdrivendevelopment yahoogroup पर संबंधित चर्चा

यदि आपने 'अनाम' एक .. पोस्ट 'इम पाया है। प्रति-प्रति-पद एक मत कुछ के लिए वोटों की गिनती करने के लिए कृपया ।

मेरी निहित रुचि शीर्ष-एन सबसेट को खोजने की है ताकि मैं निकट भविष्य में लंचबॉक्स मीट में चर्चा कर सकूं।

unit-testing tdd anti-patterns

— गिशु
स्रोत

हारून, आपको यह सब एक सा लग रहा है :) क्या टैग-लाइन्स या नारों को टिप्पणी के रूप में जोड़ना एक अच्छा विचार होगा ताकि हम कम स्क्रॉल कर सकें .. क्या कहते हैं?

— गिशु 13

1

यह अच्छी तरह से ऊपर आ रहा है .. धन्यवाद दोस्तों n gals। रखें 'उन्हें आ रहा है .. सबसे अधिक जानकारीपूर्ण SO

— IMO में से एक

2

+1 इस धागे से प्यार करो !!! और इनमें से अधिकांश इतने सच्चे और प्रचलित भी हैं!

— Chii

अच्छा धागा, इस समुदाय विकी क्यों है ???

— क्विबल्समैन

2

); - Coz यह एक जनमत सर्वेक्षण की तरह है आप कटाई प्रतिनिधि सिर्फ coz तुम विरोधी पैटर्न का सबसे आम प्रकार तैनात रहना चाहता हूँ नहीं होगा

— Gishu

70

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

— इल्जा Preuja
स्रोत

67

फ्री राइड / पिग्गबैक - जेम्स कार, टिम ओटिंगर
बल्कि किसी अन्य / विशिष्ट सुविधा / कार्यक्षमता , एक नए दावे (और इसके संबंधित कार्य अर्थात एएए से कदम) का परीक्षण करने के लिए एक मौजूदा परीक्षण मामले में सवारी करते हैं। ।

— आरोन डिगुल्ला
स्रोत

15

हाँ, यह मेरा पसंदीदा है। मुझे हर व़क्त यह करना है। ओह ... रुको ... आपने कहा कि यह एक बुरी बात थी। :-)

— मार्गदर्शनवाद

1

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

— राएवडाल

2

@ रैडवल्ड - समय के साथ, परीक्षण का नाम अब उन सभी चीजों से मेल नहीं खाता है जो यह परीक्षण करता है। इसके अलावा आपके पास इंटरस्टिंग लाइन के कारण कुछ थ्रैशिंग है; एक विफलता विफलता के सटीक कारण को इंगित नहीं करती है। उदाहरण के लिए, इस परीक्षण का एक विहित उदाहरण सभी व्यवस्था चरणों के अपारदर्शी सुपरसेट की तरह कुछ पढ़ेगा >> एक्ट >> ए एस्टर एक्ट एक्ट एक्ट्स >> एसेर बी >> एक्ट्स कुछ और >> एस्टर सी अब आदर्श रूप से यदि ए और सी हैं तो टूट, आप 2 परीक्षण विफलताओं को देखना चाहिए। उपरोक्त परीक्षण के साथ, आपको केवल एक दिखाई देगा, फिर आप A को ठीक करेंगे और अगले रन पर, यह आपको बताएगा कि अब C टूट गया है। अब कल्पना कीजिए कि 5-6 अलग-अलग परीक्षण एक साथ जुड़े हुए हैं ..

— गिशु

1

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

— राेडवल्ड

"एक विफलता विफलता का सही कारण का कहना नहीं है" कोई जोर विफलता कभी इंगित करता है कारण एक विफलता की। कार्यान्वयन विवरण में कुछ देरी की आवश्यकता है: एक प्रतिगमन विफलता के लिए डिबगिंग, कुछ टीडीडी काम के लिए विकास राज्य का आपका ज्ञान।

— राएडवल्ड २ '’’ को ११:४३

64

हैप्पी पथ

परीक्षण सीमाओं और अपवादों के परीक्षण के बिना खुश रास्तों (यानी अपेक्षित परिणाम) पर रहता है।

ज्यूनीट एंटीपैटर्न

— Geoglyph
स्रोत

कारण: या तो अतिरंजित समय की कमी या धुंधलापन। रिफैक्टर्ड समाधान: झूठी सकारात्मकता से छुटकारा पाने के लिए अधिक परीक्षण लिखने के लिए कुछ समय प्राप्त करें। उत्तरार्द्ध कारण कोड़ा की जरूरत है। :)

— Spoike

59

स्थानीय नायक

एक परीक्षण मामला जो विकास के माहौल के लिए कुछ विशेष पर निर्भर करता है जिसे चलाने के लिए लिखा गया था। परिणाम विकास बक्से पर परीक्षण पास है, लेकिन विफल रहता है जब कोई इसे कहीं और चलाने का प्रयास करता है।

द हिडन डिपेंडेंसी

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

अफसोस की बात यह है कि प्राचीन काल से कई बार ऐसा देखा गया है। जो कि किसी भी दिए गए उत्पादन सिस्टम पर सिंक से बाहर हैं, जो लगातार और किसी भी उत्पादन प्रणाली पर सिंक से बाहर हैं, उन dll के लिए जिम्मेदार तीन डेवलपर्स के साथ व्यापक परामर्श के बिना अपनी मशीन पर अकेले रहने दें। आह।

— अन्नकटा
स्रोत

यह WOMPC डेवलपर संक्षिप्त का एक अच्छा उदाहरण है। "मेरे पीसी पर काम करता है!" (आमतौर पर कहा जाता है कि आपकी पीठ पर से परीक्षक

— निकलते हैं

58

चेन गिरोह

कुछ परीक्षणों को एक निश्चित क्रम में चलाना चाहिए, अर्थात एक परीक्षण सिस्टम की वैश्विक स्थिति (वैश्विक चर, डेटाबेस में डेटा) को बदलता है और अगला परीक्षण (एस) इस पर निर्भर करता है।

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

— आरोन डिगुल्ला
स्रोत

यह सिर्फ सादा गंदा है .. टूटता परीक्षण स्वतंत्र धारणा होना चाहिए। लेकिन मैंने इसके बारे में कई जगहों पर पढ़ा है .. अनुमान है कि 'लोकप्रिय TDD' बहुत गड़बड़ है

— Gishu

56

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

स्रोत: जेम्स कैर का पद

— गिशु
स्रोत

2

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

— स्पोइक

@Spoike; यदि आप एक स्तरित वास्तुकला में हैं जो वास्तव में वर्ग की भूमिका पर निर्भर करता है; कुछ परतों में दूसरों की तुलना में अधिक निर्भरता होती है।

— krosenvold

मैंने हाल ही में देखा, एक सम्मानित ब्लॉग में, नकली मॉक रिपॉजिटरी से मॉक एंट्री सेटअप का निर्माण। WTF? सिर्फ एक वास्तविक इकाई को ही पहले स्थान पर क्यों नहीं लाया जाए। अपने आप को, मैं सिर्फ एक नकली इंटरफ़ेस से जल गया, जहाँ मेरा कार्यान्वयन NotImplementedException को चारों ओर फेंक रहा था।

— थॉमस आइड

40

साइलेंट कैचर - केली?
एक परीक्षण जो एक अपवाद को फेंकता है, तो पास हो जाता है .. भले ही अपवाद जो वास्तव में होता है, वह वह है जो डेवलपर के इच्छित उद्देश्य से भिन्न है।
इसे भी देखें: सीक्रेट कैचर

[Test]
[ExpectedException(typeof(Exception))]
public void ItShouldThrowDivideByZeroException()
{
   // some code that throws another exception yet passes the test
}

— गिशु
स्रोत

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

— जोशुआ गाल

34

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

'मैं अपने सदस्य चर को बिना सार्वजनिक किए कैसे परीक्षण करूं ... सिर्फ इकाई-परीक्षण के लिए?'

— खुलासा किया
स्रोत

2

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

— Spoike

1

इससे पहले कि मॉक इधर-उधर आए, मुझे अपने मोक्स को लिखावट के पक्ष में नकली रूपरेखाओं को छोड़ना पड़ा। मेरे परीक्षणों को वास्तविक क्रियान्वयन के साथ बांधना बहुत आसान था, असंभव के बगल में कोई भी रिफैक्टिंग करना। मैं अंतर नहीं बता सकता, Moq के अलावा, मैं शायद ही कभी इस प्रकार की गलतियाँ करता हूँ।

— थॉमस आइड

34

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

— गिशु
स्रोत

मैं समझता हूं कि अत्यधिक परीक्षण सेटअप आमतौर पर) खराब संरचित कोड या बी) अपर्याप्त मॉकिंग की ओर इशारा करता है, सही है?

— टोपेर हंट

वैसे हर स्थिति अलग हो सकती है। यह उच्च युग्मन के कारण हो सकता है। लेकिन आम तौर पर यह ओवरस्पेकिफिकेशन का मामला है, परिदृश्य में प्रत्येक और हर सहयोगी को निर्दिष्ट करना (नकली अपेक्षाएं) - यह युगल परीक्षण को लागू करता है और उन्हें भंगुर बनाता है। यदि सहयोगी को कॉल करना परीक्षण के लिए एक आकस्मिक विवरण है, तो यह परीक्षण में नहीं होना चाहिए। यह परीक्षण को छोटा और पठनीय रखने में भी मदद करता है।

— गिशु

32

गुदा जांच

एक परीक्षण जिसमें अपने कार्य को करने के लिए पागल, अवैध या अन्यथा अस्वास्थ्यकर तरीकों का उपयोग करना होता है जैसे: जावा के समुच्चय (सत्य) का उपयोग करके निजी क्षेत्रों को पढ़ना या संरक्षित क्षेत्रों / विधियों का उपयोग करने के लिए एक वर्ग का विस्तार करना या परीक्षण का उपयोग करने के लिए एक निश्चित पैकेज में परीक्षण करना। पैकेज वैश्विक क्षेत्रों / विधियों।

यदि आप इस पैटर्न को देखते हैं, तो परीक्षण के तहत कक्षाएं बहुत अधिक डेटा छुपाती हैं।

इस और इंस्पेक्टर के बीच का अंतर यह है कि परीक्षण के तहत वर्ग उन चीजों को छिपाने की कोशिश करता है जिन्हें आपको परीक्षण करने की आवश्यकता है। तो आपका लक्ष्य 100% परीक्षण कवरेज प्राप्त करना नहीं है, लेकिन कुछ भी परीक्षण करने में सक्षम होना है। एक ऐसे वर्ग के बारे में सोचें जिसके पास केवल निजी क्षेत्र हैं, run()बिना तर्क के एक विधि और कोई भी गेटर्स नहीं। नियमों को तोड़े बगैर इसका परीक्षण करने का कोई तरीका नहीं है।

माइकल बोर्गवर्ड द्वारा टिप्पणी: यह वास्तव में एक परीक्षण एंटीपैटर्न नहीं है, यह कोड परीक्षण में कमियों से निपटने के लिए व्यावहारिकता है। बेशक उन कमियों को ठीक करना बेहतर है, लेकिन यह 3 पार्टी पुस्तकालयों के मामले में संभव नहीं हो सकता है।

हारून दिगुल्ला: मैं एक तरह से सहमत हूं। हो सकता है कि यह प्रविष्टि वास्तव में "JUnit HOWTO" विकी के लिए बेहतर अनुकूल हो न कि किसी एंटीपैटर्न से। टिप्पणियाँ?

— आरोन डिगुल्ला
स्रोत

क्या यह इंस्पेक्टर जैसा नहीं है?

— १२:०४ पर गिशु

1

हम्म .. यह रेखा 'परीक्षण के तहत वर्ग को उन चीजों को छिपाने की भी कोशिश करता है जिन्हें आपको परीक्षण करने की आवश्यकता है' वर्ग और परीक्षण के बीच एक शक्ति संघर्ष को इंगित करता है। यदि इसका परीक्षण किया जाना चाहिए .. यह सार्वजनिक रूप से किसी भी तरह से पहुंच योग्य होना चाहिए .. वर्ग व्यवहार / इंटरफ़ेस के माध्यम से .. यह किसी भी तरह से अतिक्रमण को सूंघता है

— गिशु

2

npellow: Maven2 के लिए एक प्लगइन है, है ना?

— आरोन दिगुल्ला 8

1

यह वास्तव में एक परीक्षण एंटीपैटर्न नहीं है, यह परीक्षण किए जा रहे कोड की कमियों से निपटने के लिए व्यावहारिकता है। बेशक उन कमियों को ठीक करना बेहतर है, लेकिन यह 3 पार्टी पुस्तकालयों के मामले में संभव नहीं हो सकता है।

— माइकल बोर्गवर्ड 14

1

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

— यहोशू गीक

26

बिना नाम वाला टेस्ट - निक पोलो

बग ट्रैकर में एक विशिष्ट बग को पुन: उत्पन्न करने के लिए जोड़ा जाने वाला परीक्षण और जिसके लेखक को लगता है कि यह अपने नाम का कोई वारंट नहीं करता है। एक मौजूदा, अभाव परीक्षण को बढ़ाने के बजाय, एक नया परीक्षण बनाया जाता है जिसे testForBUG123 कहा जाता है।

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

— एनपीएलओ
स्रोत

7

सच है। थो जो "टेस्टमेथोड" नामक परीक्षण की तुलना में थोड़ा अधिक सहायक है

— निकोलाईडेंट

8

जब तक बगट्रैकर नहीं बदलता है, और आप पुराने ट्रैकर और उसके मुद्दे के पहचानकर्ताओं को ढीला कर देते हैं ... इसलिए परियोजना -123 का अब कोई मतलब नहीं है ....

— Chii

25

धीमी प्रहार

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

उर्फ परीक्षण जो उतनी बार नहीं चलेंगे जितने कि उन्हें होने चाहिए

— गिशु
स्रोत

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

— क्रिस वेस्ट

यह एक स्पष्ट प्रश्न है लेकिन इसे ठीक करने के सबसे सामान्य तरीके क्या हैं?

— टोपेर हंट

यह शुरू में फायदेमंद लगता है, एह?

— केव

1

@TopherHunt आमतौर पर परीक्षण धीमा होते हैं क्योंकि उनके पास कुछ महंगी निर्भरता होती है (यानी फाइल सिस्टम, डेटाबेस)। चाल निर्भरता का विश्लेषण करने के लिए है जब तक आप समस्या नहीं देखते हैं, तब कॉलस्टैक पर निर्भरता को धक्का दें। मैंने एक केस स्टडी लिखी, जहां मेरे छात्रों ने अपनी निर्भरता को ठीक करके 77 सेकंड से 0.01 सेकंड तक अपने यूनिट-टेस्ट सूट को लिया: github.com/JoshCheek/fast_tests

— यहोशू गीक

20

तितली

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

इसके विंग का बल्ला दुनिया के दूसरी तरफ तूफान का कारण बन सकता है। - एडवर्ड लोरेन्ज़, द बटरफ्लाई इफ़ेक्ट

— हारून दिगुल्ला को दिखाया
स्रोत

यहां विरोधी पैटर्न क्या है: इस तरह एक परीक्षण क्या दिखता है? क्या कोई फिक्स है? क्या कोड-अंडर-टेस्ट के लिए किसी System.DateTime.Nowभी तरह से निर्भरता को कम करने के लिए कोई तर्कपूर्ण लाभ है , जैसे कि सरल या अधिक निर्धारक इकाई परीक्षण?

— मर्लिन मॉर्गन-ग्राहम

1

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

— आरोन दिगुल्ला

इस विरोधी पैटर्न के लिए अंतर्निहित कारण यह है कि परीक्षण के तहत कोड परवाह नहीं करता है कि यह परीक्षण करने के लिए कितना प्रयास हो सकता है। तो एक डेवलपर की सनकी तितली का पंख है जो कहीं और समस्याओं का कारण बनता है।

— आरोन दिगुल्ला

19

टिमटिमा टेस्ट (स्रोत: रोमिल कॉकिंग)

एक परीक्षण जो कभी-कभी विफल होता है, विशिष्ट समय पर नहीं, और आमतौर पर परीक्षण के भीतर दौड़ की स्थिति के कारण होता है। आमतौर पर तब होता है जब किसी ऐसी चीज का परीक्षण किया जाता है जो कि एसिंक्रोनस होती है, जैसे कि जेएमएस।

संभवतः ' प्रतिरूप और प्रतीक्षा ' प्रतिमान और ' द स्लीपर ' प्रतिमान-विरोधी प्रतिमान के लिए एक सुपर सेट है ।

निर्माण विफल, ओह ठीक है, बस फिर से निर्माण चलाएं। - बेनामी डेवलपर

— स्टुअर्ट को दर्शाता है
स्रोत

@Stuart - यह वर्णन करते हुए एक वीडियो अवश्य देखें "कार स्टेल्ड - ट्राय नाउ!" videosift.com/video/… इस पैटर्न को " ट्राइ नाउ!", या

— जस्ट

1

मैंने एक बार PRGN के लिए एक परीक्षण लिखा था जो एक उचित वितरण सुनिश्चित करता था। कभी-कभी, यह यादृच्छिक पर विफल होता है। जाओ पता लगाओ। :-)

— क्रिस वेस्ट

1

यह एक अच्छा परीक्षण नहीं होगा ? यदि कोई परीक्षण कभी विफल होता है, तो आपको समस्या के स्रोत को ट्रैक करने की आवश्यकता है। मैं 9p और आधी रात के बीच विफल रहे एक परीक्षण के बारे में किसी से लड़ी। उन्होंने कहा कि यह यादृच्छिक / आंतरायिक था। यह अंततः टाइमज़ोन के साथ काम करने वाले बग का पता लगाया गया था। जाओ पता लगाओ।

— ट्रेंटन

@ क्रिसियन बनियान हैनसेन: क्या आप इसे सीड नहीं कर सकते?

— एंड्रयू ग्रिम

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

— को 'शेपर्ड'

19

रुको और देखो

एक परीक्षण जो कुछ सेट कोड चलाता है और उसके बाद एक विशिष्ट राशि को 'प्रतीक्षा' करने की आवश्यकता होती है, यदि यह 'देख' सकता है यदि परीक्षण के तहत कोड अपेक्षित रूप से कार्य करता है। एक TestMethod जो थ्रेड। स्लीप () या समकक्ष का उपयोग करता है, निश्चित रूप से एक "प्रतीक्षा करें और देखें" परीक्षण है।

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

इस तरह का परीक्षण स्थानीय हीरो भी हो सकता है क्योंकि यह धीमी बॉक्स या एक अतिभारित सीआई सर्वर पर चलने पर विफल हो जाएगा।

The Wait and See एंटी-पैटर्न द स्लीपर के साथ भ्रमित नहीं होना है ।

— npellow
स्रोत

हम्म .. वैसे मैं कुछ इस तरह का उपयोग करता हूं। मैं मल्टी-थ्रेडेड कोड का परीक्षण कैसे कर पाऊंगा?

— गिशु

@ Gishu, क्या तुम सच में समवर्ती चलने वाले कई धागों का परीक्षण करना चाहते हो? मैं केवल यूनिट परीक्षण की कोशिश करता हूं जो भी () विधि अलगाव में करता है। ऐसा करने का एक आसान तरीका रन टेस्ट () है - जो यूनिट टेस्ट से स्टार्ट () के बजाय ब्लॉक करेगा।

— npellow 8

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

— क्रिस वेस्ट

एक उदाहरण: madcoderspeak.blogspot.com/2008/11/… Brew बटन evt। पर्यवेक्षक अंतराल पर मतदान कर रहा है और बदली हुई घटनाओं को उठा रहा है .. जिस स्थिति में मैं एक देरी जोड़ देता हूं ताकि परीक्षण से बाहर निकलने से पहले मतदान सूत्र को चलाने का मौका मिल जाए।

— गिशु

मुझे लगता है कि कार्टून लिंक टूट गया है।

— एंड्रयू ग्रिम

17

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

— Gishu
स्रोत

1

यह भी हो सकता है कि परीक्षण के तहत वर्ग बहुत अधिक करने की कोशिश कर रहा हो।

— माइक दो

16

विशाल

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

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

— गिशु
स्रोत

15

मुझे विश्वास है कि जब मैं कुछ चमकती जीयूआई देखूंगा तो
एक जीयूआई के माध्यम से ऐप का परीक्षण करने के साथ एक अस्वास्थ्यकर निर्धारण / जुनून 'एक वास्तविक उपयोगकर्ता की तरह'

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

"आपको समझना चाहिए कि देखकर विश्वास हो रहा है, लेकिन यह भी जानिए कि विश्वास देख रहा है।" - डेनिस वेटली

— गिशु
स्रोत

1

अगर आपको लगता है कि GUIs को फ्लैश करना गलत है, तो मैंने किसी ऐसे व्यक्ति को देखा, जिसने एक JUnit टेस्ट लिखा, जिसने GUI को शुरू किया और इसे जारी रखने के लिए उपयोगकर्ता इंटरैक्शन की आवश्यकता थी। इसने बाकी के सूट को लटका दिया। परीक्षण स्वचालन के लिए इतना!

— Spoike

मैं असहमत हूं। GUI का परीक्षण कठिन है, लेकिन वे भी त्रुटियों का एक स्रोत हैं। नहीं उन्हें परीक्षण आलसी है।

— रे

3

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

— गिशु

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

— मेरलिन मॉर्गन-ग्राहम

1

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

— स्पाइक

14

द स्लीपर, उर्फ माउंट वेसुवियस - निक पोलो

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

'द स्लीपर' को ' वेट एंड सी ' विरोधी पैटर्न के साथ भ्रमित नहीं होना है ।

उस कोड को वर्ष 2000 से बहुत पहले बदल दिया जाएगा - 1960 में कई डेवलपर्स

— एनपीएलओ
स्रोत

मैं इसे एक निष्क्रिय ज्वालामुखी कहता हूं :) .. लेकिन मुझे पता है कि आप किस बारे में बात कर रहे हैं .. उदाहरण के लिए एक तारीख के रूप में एक भविष्य की तारीख के रूप में एक लिखित परीक्षा के लिए एक वर्तमान / पिछली तारीख बन जाएगी जब वह तारीख जाता है .. परीक्षण तोड़कर। क्या आप एक उदाहरण पोस्ट कर सकते हैं .. इसे स्पष्ट करने के लिए।

— गिशु

@ गिषु - १। मैं भी यही सोच रहा था, लेकिन दोनों के बीच फैसला नहीं कर सका। मैंने इसे थोड़ा स्पष्ट करने के लिए शीर्षक को अद्यतन किया;)

— npellow

11

द डेड ट्री

एक परीक्षण जहां एक ठूंठ बनाया गया था, लेकिन परीक्षण वास्तव में नहीं लिखा गया था।

मैंने वास्तव में इसे हमारे उत्पादन कोड में देखा है:

class TD_SomeClass {
  public void testAdd() {
    assertEquals(1+1, 2);
  }
}

मैं यह भी नहीं जानता कि उस बारे में क्या सोचना है।

— रेवरेंड गोंजो
स्रोत

8

:) - प्रक्रिया अनुपालन पिछले दरवाजे के रूप में भी जाना जाता है।

— गिस्सु

1

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

— मार्वो

11

आज इसके द्वारा बिट गया:

वेट फ्लोर :
परीक्षण ऐसा डेटा बनाता है जो कहीं न कहीं बना रहता है, लेकिन परीक्षण समाप्त होने पर साफ नहीं होता है। इसके कारण परीक्षण (उसी परीक्षण, या संभवतः अन्य परीक्षण) बाद के परीक्षण रन पर विफल हो जाते हैं ।

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

— Zac थॉम्पसन
स्रोत

गीले फर्श से बचने के लिए आप जूनट के अस्थायी-फ़ोल्डर-नियम का उपयोग कर सकते हैं।

— डेवफ़र

इस तरह का एक निरंतर एकीकरण विरोधी पैटर्न से संबंधित है। CI में, प्रत्येक डेवलपर के पास अपना कार्य स्थान और संसाधन होना चाहिए, और निर्माण मशीन होनी चाहिए और साथ ही उसका स्वयं का वातावरण भी होना चाहिए। तब आप अनुमति की समस्याओं जैसी चीजों से बचते हैं (या शायद आप उन्हें छिपाते हैं ताकि वे केवल उत्पादन में बदल जाएं।)

— Marvo

11

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

— गिशु
स्रोत

10

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

[Test]
public void ShouldNotThrow()
{
   DoSomethingThatShouldNotThrowAnException();
}

— Gishu
स्रोत

2

यह वास्तव में एक मान्य परीक्षण हो सकता है, मेरी राय में - विशेष रूप से प्रतिगमन परीक्षण के रूप में।

— इलजा प्रीउ डे

सॉरी फिर से इस साइलेंट कैचर से उलझन में पड़ गया ... यूनिट परीक्षणों को 'यह काम करना चाहिए' कहने के बजाय जो भी परीक्षण किया जा रहा है, उसके बारे में स्पष्ट रूप से इरादा करना चाहिए .. (+1 tp कुछ भी नहीं से बेहतर है। अगर आप विरासत प्रतिगमन में हैं। देश)

— गिशु

1

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

— थॉमस आइड

4

कुछ रूपरेखाओं में एक Assert.DoesNotThrow(SomeDelegateType act)शैली मुखरता है जो विशेष रूप से इस तरह के मामलों में उपयोग की जा सकती है। मुझे यह एक टेस्ट केस होने की तुलना में कम सकल लगता है जो तब सफल होता है जब कोई कंस्ट्रक्टर नॉन-नल लौटाता है, लेकिन जब कंस्ट्रक्टर फेंकता है तो वह विफल हो जाता है। एक कंस्ट्रक्टर कभी भी अशक्त नहीं लौटेगा। (नोट: केवल उन भाषाओं पर लागू होता है जहाँ एक निर्माता को गैर-अशक्त लौटने की गारंटी दी जाती है)

— मर्लिन मॉर्गन-ग्राहम

10

द पर्यावरण पर्यावरण

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

ये परीक्षण रुक-रुक कर होंगे, और डेवलपर्स को यह कहते हुए छोड़ देंगे कि 'बस इसे फिर से चलाएं'।

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

— gcrain
स्रोत

@gcrain .. परीक्षण निर्धारक होना चाहिए। IMO एक बेहतर तरीका यह होगा कि परीक्षण से पहले और बाद में परीक्षण और सफाई के लिए एक 'जाने-माने-इन-द-टीम' पोर्ट का उपयोग करें ताकि यह हमेशा उपलब्ध रहे ...

— Gishu

1

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

— gcrain

10

ट्यूरिंग टेस्ट

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

हाय पागल। - नई प्रशिक्षु के लिए दुनिया का सबसे स्मार्ट कंप्यूटर (एक पुरानी अमीगा कॉमिक से)।

— रेव्स , 2 उपयोगकर्ता 57% bhumphreys
स्रोत

10

फोर्टी फुट पोल टेस्ट

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

— रेव्स , 2 यूजर्स 67% भौमफ्रीस
स्रोत

9

Doppelgänger

किसी चीज़ का परीक्षण करने के लिए, आपको एक ही नाम और पैकेज के साथ एक नई कक्षा में परीक्षण के तहत कोड के कुछ हिस्सों को कॉपी करना होगा और आपको यह सुनिश्चित करने के लिए कि इसे पहले दिखाई दे रहा है, यह सुनिश्चित करने के लिए क्लासपैथ जादू या कस्टम क्लास लोडर का उपयोग करना होगा यूपी)।

यह पैटर्न छिपी हुई निर्भरताओं की एक अस्वास्थ्यकर मात्रा को इंगित करता है जिसे आप परीक्षण से नियंत्रित नहीं कर सकते हैं।

मैंने उसके चेहरे की तरफ देखा ... मेरा चेहरा! यह एक दर्पण की तरह था लेकिन मेरे खून को जम गया।

— हारून दिगुल्ला को दिखाया
स्रोत

7

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

मुझे नहीं पता कि यह क्या करता है ... मैं इसे वैसे भी जोड़ रहा हूं, बस मामले में। - बेनामी डेवलपर

— गिशु
स्रोत

7

द टेस्ट इट ऑल

मेरा मानना है कि अब तक इसका उल्लेख नहीं किया गया है, लेकिन परीक्षण एकल जिम्मेदारी सिद्धांत को नहीं तोड़ना चाहिए ।

मैं इस पर कई बार आया हूं, इस नियम को तोड़ने वाले परीक्षण परिभाषा बनाए रखने के लिए एक बुरा सपना हैं।

— thegreendroid
स्रोत

6

रेखा हिटर

पहली नज़र में परीक्षण सब कुछ कवर करता है और कोड कवरेज उपकरण इसकी पुष्टि 100% के साथ करते हैं, लेकिन वास्तव में परीक्षण बिना किसी आउटपुट विश्लेषण के केवल हिट कोड होते हैं।

कवरेज-बनाम-पहुंच योग्य-कोड

— रुस्लान दज़बर्बोव को दर्शाता है
स्रोत