适当的单元测试技术

Question

While Using TDD I found myself needing to test a constant (final) hashmap which contains lookup values ( PLEASE SEE REASON WHY THIS WAS THE CASE UNDER UPDATE )

See below

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");
}}; 

With TDD its stressed to test one thing at a time so i started calling my class verifying the validity of each of the elements as below.

TEST STYLE 1

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

after writing the third test I thought it was pretty ridiculous and created a temporary lookup with the reverse key value pairs and began calling in a loop to test as below.

TEST STYLE 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)));
        }
    } 

My Question is this; is it better to use style 1 for unit testing or is it better to use style 2.

I see pros and cons for both. for example style 1 is very concise, test only one thing and easier to understand. cons for style 1 besides doing a ton of typing the Test suite will blow up with many trivial test. Pros for style 2 is less unit tests. cons for style 2 has a bit of complexity and may be testing more than one thing but I would argue its only testing one thing the validity of the constant hashmap.

UPDATE I've received a decent amount of blowback from this question so let me further explain. Its not the constant I care about per se but validating the different cases of my code. This Was a practice problem (Practicing TDD Via Katas) not production code. The problem was converting numbers to words so what I care about in my unit testing is ensuring I could properly handle the different possible numbers. There were other constants that I didn't include for example constant storing teen numbers (11, 12, 13...) and tensDigits(20, 30, 40...). Its fairly easy to make a typo here.

Answer 1

Approach #1 gets the job done, just with an obnoxious amount of cut-n-pasting. Approach #2 fixes that, but at the expense that the tests aren't independent: if one test fails the following ones don't run. Fixing one test just to find a bunch of new ones now fail is pretty annoying. You can improve on this by making a parameterized test, here's 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));
    }
}

The parameterized test includes a collection of input/expected-output pairs, for each pair the input and output get passed into the constructor call for the test and the test method is called on the new test instance. The looping is kept in the test framework and out of the test, and each test succeeds or fails independently of the others.