यूनिट एक विधि है कि एक और प्रणाली को बुलाती परीक्षण

Question

क्या इकाई परीक्षण करने के लिए सबसे अच्छा तरीका है एक विधि है कि उदाहरण के लिए, कई तरीकों में कहता है:

modify(string value) 
{ 
    if(value.Length > 5) replaceit(value); 

    else changeit(value); 
} 

यह छद्म कोड एक संशोधित विधि (वर्तमान में) या तो कॉल है replaceit() या changeit()। मैंने पहले ही replaceit और changeit के लिए परीक्षण लिखे हैं, इसलिए संशोधित करने के लिए एक नया परीक्षण लिखना कोड का एक ही सेट 99% होगा। मुझे इसका परीक्षण करने की ज़रूरत है क्योंकि यह भविष्य में बदल सकता है।

तो क्या मैं मौजूदा टेस्ट कोड पेस्ट कॉपी करता हूं? परीक्षण कोड को एक सामान्य समारोह में ले जाएं? कोई अन्य विचार? मुझे यहां सबसे अच्छा अभ्यास नहीं है।

Answer 1

यह क्लासिक राज्य-आधारित परीक्षण बनाम व्यवहार-आधारित परीक्षण परिदृश्य है।

इस हास्यास्पद सरल उदाहरण परीक्षण में आउटपुट ठीक है। हालांकि, कुछ बिंदु पर, आप परीक्षणों में भाग लेंगे जहां निष्पादन के बाद राज्य का निरीक्षण जटिल है। इसके बजाय आप व्यवहार की जांच करना चाहते हैं (उदा। सत्यापित करें कि परिवर्तन को विशिष्ट मान के साथ बुलाया गया था)।

उस बिंदु पर आपको शायद मोनो ऑब्जेक्ट फ्रेमवर्क जैसे Rhino.Mocks (.Net) या Mockito (Java) में देखना चाहिए और अधिक इंटरफ़ेस आधारित कोड लिखना शुरू करना चाहिए।

Answer 2

यदि आपने पहले से ही replaceit() और changeit() का परीक्षण किया है, तो केवल एक चीज जिसे आपने परीक्षण करने के लिए छोड़ा है, वह स्थिति है। टेस्ट modify() कुछ मानों के साथ यह सुनिश्चित करने के लिए कि यह सही शर्तों के तहत सही कार्य (null और Strings लंबाई 4, 5, और 6 के उदाहरण कोड के लिए सही कार्य करता है)।

Answer 3

ठीक है, नहीं, आपका टेस्ट कोड 99% समान नहीं होगा, क्योंकि आप वास्तव में यहां कुछ अलग-अलग परीक्षण कर रहे हैं, जब तक कि प्रतिस्थापन, परिवर्तन और संशोधित न हो, सभी मूल्यों को वापस न करें।

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

Answer 4

इस मामले में "परीक्षण कोड" क्या है? परिणाम सेट अप करना और जांचना? यदि ऐसा है, तो मैं इसे एक अलग तरीके से दोबारा कर दूंगा और प्रत्येक परीक्षण से इसका इस्तेमाल करूंगा। मैं केवल तभी ऐसा करूंगा जब इसकी एक बड़ी मात्रा हो - हालांकि, उस विधि के कोड को पढ़कर, परीक्षण की हर चीज को देखने में सक्षम होने के लिए एक पठनीयता लाभ होता है।

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

Answer 5

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

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

Answer 6

बस modify का परीक्षण करें।

Modify कुछ मान दिए जाने पर कुछ मान वापस करने के लिए माना जाता है।

यह महत्वहीन है कैसे संशोधित अपने काम करता है - केवल कि यह अपने काम करता है।

और यदि भविष्य में, आप अलग-अलग तरीकों (या कोई विधियों) का उपयोग करने के लिए modify बदलते हैं, तो यह आपके परीक्षणों को प्रभावित नहीं करता है, और नहीं, और नहीं करेगा।

उस ने कहा, replaceit' and परिवर्तन 'का भी परीक्षण करें।

Answer 7

आपको मूल रूप से 2 परीक्षणों की आवश्यकता है।

1) "क्विक ब्राउन फॉक्स कूदता" जैसे स्ट्रिंग में पास करें! (पांच से अधिक लंबाई) सुनिश्चित करें कि मूल्य "फू" की तरह एक स्ट्रिंग में replaceit(...)

2) दर्रा से प्रभावित है बनाता है (लंबाई पांच से भी कम) और changeit(...)

से लगता है कि मूल्य को प्रभावित किया है है (छद्म कोड में) आपका परीक्षण इस प्रकार दिखाई देंगे:

testLongValue() { 
    string testValue = "A value longer than 5 chars"; 
    string expected = "Replaced!"; 
    string actual = modify(testValue); 
    assertEqual(expected, actual); 
} 

testShortValue() { 
    string testValue = "len4"; 
    string expected = "Changed!"; 
    string actual = modify(testValue); 
    assertEqual(expected, actual); 
} 

जाहिर है मैं अगर मुझे पता था कि (क्या replacit) और changeit() करना चाहिए थे आप एक और अधिक यथार्थवादी उदाहरण दे सकता है, लेकिन यह आप देना चाहिए विचार। यदि यह इसे वापस करने के बजाय मूल मान संदर्भ को बदलता है, तो आप कॉल के बाद परीक्षण मूल्य को वास्तविक मान के रूप में उपयोग कर सकते हैं।

Answer 8

if (value.length > 5) तरह सीमा की स्थिति का परीक्षण जब आप सुनिश्चित करें कि आपके परीक्षण डाटा लंबाई 4, 5, या 6 है value का मान शामिल हैं चाहिए।

Answer 9

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

Answer 10

आपके पास कई विकल्प हैं। कौन सा सबसे अच्छा है उन विवरणों पर निर्भर करता है जो आपके प्रश्न से स्पष्ट नहीं हैं।

• परीक्षण modify जैसे कि यह एक असंबंधित विधि थी। लाभ: यह किसी बिंदु पर एक हो सकता है।
• बस परीक्षण करें कि आपको सही कथन मिल गया है। यही है, परीक्षणों को केवल इतना परीक्षण करें कि आपको आवश्यक कार्यान्वयन लिखने के लिए मजबूर किया गया है (जहां replaceit और changeit पर कॉल करना केवल सरल कार्यान्वयन है जो संभवतः पर काम कर सकता है। यदि आप टीडीडी का अभ्यास कर रहे हैं, तो यह स्वाभाविक रूप से आपके पास आना चाहिए। लाभ: उच्च डुप्लीकेट प्रयास के बिना उच्च परीक्षण कवरेज
• सबक्लास और ओवरराइड विधि (यह "लीगेसी कोड के साथ प्रभावी ढंग से काम कर रहे" पुस्तक से एक निर्भरता तोड़ने वाली तकनीक है): एक सबक्लास पर विधि का परीक्षण करें जिसे आप पूरी तरह परीक्षण उद्देश्यों के लिए पेश करते हैं, जो डिब्बाबंद उत्तरों के साथ replaceit और changeit ओवरराइड करता है या ताकि वे सेंसिंग चर सेट कर सकें (चर जो इंगित करते हैं कि विधि को सही मान के साथ कहा गया है)। लाभ: possibl y अपने परीक्षणों को सरल बनाएं (या नहीं), कभी-कभी केवल परीक्षण को संभव बनाते हैं।
• उस कक्षा के लिए इंटरफ़ेस समेत replaceit और changeit विधियों के लिए एक नई कक्षा निकालें। modify परीक्षण करते समय इंटरफ़ेस स्टब या मॉक। लाभ: दोनों आपके डिजाइन को अधिक टेस्टेबल और सामान्य रूप से बेहतर (या नहीं) बेहतर decoupled/पुन: प्रयोज्य बना सकते हैं।

Answer 11

वरीयता

1. के आदेश में संशोधित (परीक्षण) सिर्फ 2 परिदृश्यों (यदि stmt के प्रत्येक आर्म) है, तो मैं फार्म के संशोधित के लिए 2 परीक्षण लिखना चाहते हैं।
   यदि प्रतिस्थापन (मूल्य) का अपेक्षित परिणाम निर्धारित करना आसान है ..

।

public TestModifyIfValueLength..() 
    { 
     string expectedValue = .. ;// literal result of replaceit(value) 
     Assert.Equals(expectedValue, modify("asd")); 
    } 

1. यदि नहीं, तो एक ठूंठ उपयोग करने पर विचार (उपयोग उपवर्ग और changeit, replaceit ओवरराइड) सत्यापित करें कि सही विधि बुलाया गया था।
2. यदि स्टब बहुत अधिक काम है, तो मॉक चीज करें। प्रतिस्थापन पर एक इंटरफ़ेस और सेटअप अपेक्षाएं निकालें, प्रतिस्थापित करें।

अनुमान

• आप replaceit (मान) और changeit (मूल्य) है, जो परीक्षण (जैसे सभी के लिए सीमा की स्थिति) उन 2 तरीकों व्यापक के लिए परीक्षण किया है।
• प्रतिस्थापन() और परिवर्तन() सार्वजनिक विधियां हैं .. यदि नहीं, तो आपको केवल सार्वजनिक तरीकों के खिलाफ परीक्षण लिखने पर विचार करना चाहिए। परीक्षण कोड जानने के बिना आपको निजी तरीकों को ट्विक/चक करने के लिए स्वतंत्र होना चाहिए।

Answer 12

आप विधियों में से एक func बना सकते हैं और उन funcs mock। या, आप वर्चुअल विधियां बना सकते हैं और राइनो मोक्स का उपयोग कर सकते हैं - आंशिक नकली, आप उन आभासी तरीकों का नकल कर सकते हैं।