उचित इकाई परीक्षण तकनीक

Question

जबकि TDD का उपयोग करते हुए मुझे लगने लगा एक निरंतर (अंतिम) hashmap जो देखने मूल्यों (कृपया कारण दिखाई देता इसलिए यह अद्यतन के तहत मामला था) शामिल हैं परीक्षण करने के लिए की आवश्यकता होगी,

private static final Map<Integer,String> singleDigitLookup = new HashMap<Integer, String>(){{ 
     put(0,"Zero");put(1,"One");put(2,"Two");put(3,"Three");put(4,"Four");put(5,"Five");put(6,"Six");put(7,"Seven"); 
     put(8,"Eight");put(9,"Nine"); 
}}; 

नीचे देखें

TDD के साथ अपने एक समय में एक बात का परीक्षण करने पर बल दिया तो मैं नीचे के रूप में तत्वों में से प्रत्येक की वैधता की पुष्टि करने मेरी कक्षा कहना शुरू कर दिया।

टेस्ट स्टाइल 1

@Test 
public void whenWordIsOneThenReturn1(){ 
    assertEquals(1, WordToIntegerConverter.toInteger("One")); 
} 

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

टेस्ट स्टाइल 2

@Test 
    public void whenWordIsZeroThroughNineReturnIntegerConversion(){ 
     HashMap<Integer, String> lookup = new HashMap<Integer, String>(){{ 
      put(0,"Zero");put(1,"One");put(2,"Two");put(3,"Three");put(4,"Four");put(5,"Five"); 
      put(6,"Six");put(7,"Seven");put(8,"Eight");put(9,"Nine"); 
     }}; 
     for(int i = 0; i < 10; i++) { 
      assertEquals(i, WordToIntegerConverter.toInteger(lookup.get(i))); 
     } 
    } 

मेरे प्रश्न यह है; यह बेहतर इकाई परीक्षण के लिए शैली 1 उपयोग करने के लिए है या यह बेहतर शैली 2.

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

अद्यतन मुझे इस प्रश्न से एक अच्छी तरह से झटका लगा है इसलिए मुझे और समझाएं। यह निरंतर नहीं है कि मैं प्रति से परवाह करता हूं लेकिन मेरे कोड के विभिन्न मामलों को मान्य करता हूं। यह एक अभ्यास समस्या थी (टीडीडी वाया कट्स का अभ्यास) उत्पादन कोड नहीं। समस्या संख्याओं को शब्दों में परिवर्तित कर रही थी, इसलिए मेरी यूनिट परीक्षण में मुझे किस चीज की परवाह है यह सुनिश्चित करना है कि मैं अलग-अलग संभावित संख्याओं को सही ढंग से संभाल सकता हूं। ऐसे अन्य स्थिरांक थे जिन्हें मैंने उदाहरण के लिए शामिल नहीं किया था, उदाहरण के लिए निरंतर किशोर संख्याएं (11, 12, 13 ...) और दसियों के डिगिट्स (20, 30, 40 ...)। यहाँ एक टाइपो बनाने के लिए काफी आसान है।

Answer 1

कार्य # 1, काम किया हो जाता है सिर्फ कट-एन-चिपकाने के एक अप्रिय राशि के साथ। दृष्टिकोण # 2 ठीक करता है, लेकिन खर्च पर कि परीक्षण स्वतंत्र नहीं हैं: यदि एक परीक्षण विफल रहता है तो निम्नलिखित नहीं चलते हैं। नए परीक्षणों को खोजने के लिए सिर्फ एक परीक्षण को ठीक करना असफल रहा है। आप एक पैरामिट्रीकृत परीक्षण करके इस पर सुधार कर सकते हैं, यहाँ प्रत्येक जोड़ी इनपुट और आउटपुट परीक्षण के लिए निर्माता कॉल में पारित करने के लिए, an example from junit's wiki:

@RunWith(Parameterized.class) 
public class FibonacciTest { 
    @Parameters 
    public static Collection<Object[]> data() { 
     return Arrays.asList(new Object[][] {  
       { 0, 0 }, { 1, 1 }, { 2, 1 }, { 3, 2 }, { 4, 3 }, { 5, 5 }, { 6, 8 } 
      }); 
    } 

    private int fInput; 

    private int fExpected; 

    public FibonacciTest(int input, int expected) { 
     fInput= input; 
     fExpected= expected; 
    } 

    @Test 
    public void test() { 
     assertEquals(fExpected, Fibonacci.compute(fInput)); 
    } 
} 

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