मुझे अपने टेस्ट कोड का परीक्षण कैसे करना चाहिए?


22

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

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

मुझे ऐसा लगता है कि ऐसा करने का सबसे अच्छा तरीका यह सुनिश्चित करना होगा कि परीक्षण छोटी गाड़ी कोड के लिए विफल रहता है। * अगर मैं 2 मिनट वैकल्पिक रूप से कोड में कीड़े जोड़ रहा हूं और यह सुनिश्चित करता है कि यह विफल हो गया है, तो मुझे विश्वास की एक स्वीकार्य डिग्री होनी चाहिए। परीक्षण 'काम'। यह मुझे मेरे दूसरे सवाल पर लाता है: यह सुनिश्चित करने के लिए कि परीक्षण के मामलों से पकड़े जाने के लिए कीड़े को पेश करने के अच्छे तरीके क्या हैं? क्या मुझे केवल बेतरतीब ढंग से टिप्पणी करनी चाहिए, सुनिश्चित करें कि if-elseइसकी स्थिति को नकारने से एक गलत शाखा चलती है, और साइड-इफेक्ट्स आदि के साथ कोड के निष्पादन क्रम को बदल दें, जब तक कि मैं संतुष्ट न हो जाऊं मेरे परीक्षण सबसे अधिक पकड़ लेंगे।आम कीड़े? पेशेवर डेवलपर्स कैसे मान्य करते हैं कि उनके परीक्षण वास्तव में वही करते हैं जो वे करने वाले हैं? क्या वे सिर्फ परीक्षण के काम को मानते हैं, या वे समय के साथ-साथ उनका परीक्षण करते हैं? यदि हां, तो वे परीक्षण कैसे करते हैं?

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

* मैं देख सकता था कि परीक्षण 'बग-मुक्त' कोड का परीक्षण करते समय गुजरता है, लेकिन परीक्षण के लिए कल्पना के रूप में कोड का उपयोग करना बहुत पीछे की ओर लगता है ...


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


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

जवाबों:


16

TDD के लिए मानक प्रवाह है:

  1. एक असफल परीक्षा लिखें। (लाल)
  2. सबसे छोटा कोड परिवर्तन करें जो इसे पास करता है (हरा)
  3. परावर्तक (इसे हरा रखते हुए)

इस मामले में आपके परीक्षणों का चरण चरण 1 है - यह सुनिश्चित करना कि कोई भी कोड परिवर्तन करने से पहले परीक्षण विफल हो जाता है।

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

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


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

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

@ChristianHackl उस विकास के स्तर पर यह एक पूर्ण कार्यान्वयन है! आपको एक (या अधिक) परीक्षण जोड़ना होगा जो पहले अपेक्षित व्यवहार को आगे बढ़ाने में विफल रहता है। बाद में आप इसे लागू करते हैं, जिससे ये परीक्षण हरे हो जाते हैं।
एंडी

@ एंडी: विस्तृत वर्णन करने के लिए कि यह एक आदर्श कार्यान्वयन कैसे है जब मेरे पास कोड और टेस्ट दोनों में बग है, और एक मुझे दूसरे को नोटिस करने से रोकता है? (कोड में बग यह है कि एक खाली सूची लौटा दी गई है, और परीक्षण में बग यह है कि मैं nullखाली के लिए जांच करता हूं या नहीं।)
क्रिश्चियन हैकल

@ChristianHackl आप खाली चेक के अनुसार सही हैं। कि, वास्तव में, एक परीक्षण में भी किया जाना चाहिए। जब आप परीक्षण के लिए अपनी आवश्यकताओं का अनुवाद करते हैं, तो कदम से कदम, कीड़े के लिए बहुत कम जगह होती है। सिवाय उन लोगों के जब आप ऐनक से चिपके नहीं रहते (जैसे एक खाली-खाली चेक को देखना)।
एंडी

9

एक दृष्टिकोण म्यूटेशन परीक्षण है , जोस्टर जैसे उपकरण का उपयोग कर :

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


4

टेस्ट के लिए टेस्ट? उस सड़क पर मत जाओ। फिर आपको परीक्षणों के लिए परीक्षणों के लिए परीक्षणों की आवश्यकता होगी, और फिर परीक्षणों के लिए परीक्षणों के लिए परीक्षण ... आप कहाँ रुकते हैं?

सामान्य परीक्षण प्रवाह इस तरह से जाता है, और एक डेवलपर के रूप में, आप अपना अधिकांश समय 1-3 बिंदुओं पर व्यतीत करेंगे:

  1. कोड
  2. इकाई परीक्षण
  3. एकीकरण परीक्षण
  4. सिस्टम / अन्य स्वचालित
  5. क्यूए / मानव परीक्षक

अगर मैं 2 मिनट वैकल्पिक रूप से कोड में कीड़े जोड़ रहा हूँ (...)

आपका कोड अंततः अपने स्वयं के बग को "विकसित" करेगा, समय को हाथ से शुरू करने में समय बर्बाद न करें। उल्लेख नहीं करने के लिए, एक ऐसी चीज है जिसे आप अग्रिम रूप से बग के बारे में जानते थे? कीड़े आ जाएंगे, मुझे इस बारे में चिंता नहीं होगी।

क्या मुझे केवल बेतरतीब ढंग से टिप्पणी करनी चाहिए, सुनिश्चित करें कि अगर उसकी स्थिति को नकारने से एक और की गलत शाखा चलती है (...)

यह वास्तव में सत्यापित करने के लिए एक व्यवहार्य दृष्टिकोण है कि क्या आप वास्तव में परीक्षण करते हैं कि आप क्या सोचते हैं। मुझे नहीं लगता कि यह हमेशा अच्छा होता है क्योंकि यह उसी समस्या से ग्रस्त होता है जैसे "टेस्ट फॉर टेस्ट फॉर टेस्ट ..." बात: जब आप 100% कार्यों का परीक्षण कर रहे कोड जानने को बदलना बंद कर देते हैं?

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


3
मुझे अपने कोड के अपने कीड़े बढ़ने की चिंता नहीं है, मैं अपने परीक्षणों के बारे में चिंतित हूं जब वे ऐसा करते हैं। यदि मेरे परीक्षण दोषपूर्ण हैं, तो वे अपना काम नहीं करेंगे और मुझे लगता है कि मुझे बग की एक निश्चित श्रेणी से छुटकारा मिल गया है जब वे वास्तव में अभी भी मौजूद हैं, बस अपना काम कठिन बना रहा हूं क्योंकि मैं गलत परीक्षा परिणामों को देख रहा हूं (पास होना चाहिए जब वे असफल हो जाएं)।
गॉर्डन गुस्ताफसन

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

3

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


0

आप अपने यूनिट टेस्ट को एक बार टेस्ट करते हैं जब आप इसे डिबगर में लिखते हैं। तब आप इसे अकेला छोड़ देते हैं और इसके बारे में भूल जाते हैं। यहां कोई समस्या नहीं है।

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


-2

नहीं है एक परिवर्तन का परीक्षण है कि मूल्यांकन करता है और उपायों उपयुक्तता और परीक्षण की गुणवत्ता।

हम इसका उपयोग "परीक्षण" का मूल्यांकन करने के लिए कर सकते हैं।

संक्षेप में, हम परीक्षण का परीक्षण करके अपने परीक्षण (जैसे टेस्टा) का मूल्यांकन कर सकते हैं और कोड और उसके उत्परिवर्तन कोड (मूल कोड के साथ बहुत समान लेकिन थोड़ा अलग कोड) के बीच अंतर पा सकते हैं।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.