Evolutionary architecture and emergent design: test-driven design, part 2nd

This article is the second part of a two-part article that discusses how to use TDD to write tests before writing code and to create better designs through this process. In the 1th part, I wrote a version of the complete number finder using the Post test development method (writing the test after writing the code). Then, use TDD (write the tests before you write the code, so you can write another version with the design of the test driver code). At the end of part 1th, I found that I made a fundamental mistake in preserving the type of data structure used to hold the complete list: I initially chose ArrayList based on intuition, but later found that Set was more appropriate. I will start with this issue to discuss how to improve the quality of the test and check the quality of the final code.

Test quality

A test with a better Set abstraction is shown in Listing 1:

Listing 1. Unit tests that use better Set abstractions

_@Test　public　void　add_factors()　{
　　 Set<Integer>　expected　=
　　　　　　 new　HashSet<Integer>(Arrays.asList(1,　2,　3,　 6));
　　 Classifier4　c　=　new　Classifier4(6);
　　 c.addFactor(2);
　　 c.addFactor(3);
　　 assertThat(c.getFactors(),　is(expected));
}

This code tests one of the most critical parts of my problem domain: getting the number factor. I want to thoroughly test this step, because it is the most complex part of the problem, so it is also the most prone to error. However, it contains a cumbersome construct: New HashSet (Arrays.aslist (1, 2, 3, 6)); Even with modern IDE support, this line of code is awkward to write: Enter new, enter has, execute Code Explorer, enter <int, and execute Code Explorer again, it's too much trouble. I'm going to make it easier.

Damp test

Andy Hunt and Dave Thomas's pragmatic programmer put forward many good programming practices, one of which is DRY (don ' t Repeat yourself, don't repeat yourself) principle. This principle advocates eliminating all repetition from the code, because repetition often leads to errors. However, DRY does not apply to unit tests. Unit tests often need to test for subtle differences in code behavior, so it involves similar and repetitive situations. For example, to test various situations in different tests, it is often necessary to copy and paste the code to arrive at the expected results in Listing 1 (New HashSet (Arrays.aslist (1, 2, 3, 6)).

For TDD, my rule of thumb is that tests should be damp, but don't get soaked. That is, there can be some duplication in the test (and this is unavoidable), but you should not create clumsy duplicate structures. So I'm going to refactor the test and provide a private helper method that handles this common creation statement, as shown in Listing 2:

Listing 2. Help to keep testing the appropriate humidity

private　 Set<Integer>　expectationSetWith(Integer...　numbers)　{
　　 return　new　HashSet<Integer>(Arrays.asList(numbers));
}