Question

I’m learning Java by reading “Head First Java” and by doing all the puzzles and excercies. In the book they recommend to write TestDrive classes to test the code and clases I’ve written, that’s one really simple thing to do, but by doing this I think I can’t fully test my code because I’m writing the test code knowing what I want to get, I don’t know if it makes any sense, but I was wondering if there’s any way of testing my code in a simple way that it tell’s me what isn’t working correctly. Thanks.

Answer 1

What do we mean by code? When Unit testing, which is what I think we’re talking about here, we are testing specific methods and classes.

I think I can’t fully test my code
because I’m writing the test code
knowing what I want to get

In other words you are investigating whether some code fulfils a contract. Consider this example:

 int getInvestvalue( int depositCents, double annualInterestRate, int years) {

 }

What tests can you devise? If you devise a good set of tests you can have some confidence in this routine. So we could try these kinds of input:

  deposit 100, rate 5.0, years 1 : expected answer 105
  deposit 100, rate 0, years 1 : expected answer 100
  deposit 100, rate 10, years 0 : expected anwer 100

What else? How about a negative rate?

More interestingly, how about a very high rate of interest like 1,000,000.50 and 100,000 years, what happens to the result, would it fit in an integer – the thing about devising this test is that it challenges the interface – why is there no exception documented?

The question then comes: how do we figure out those test cases. I don’t think there is a single approach that leads to building a comprehensive set but here’s a couple of things to consider:

1. Edges: Zero, one, two, many. In my example we don’t just do a rate of 5%. We consider especially the special cases. Zero is special, one is special, negative is special, a big number is special …
2. Corner cases: combinations of edges. In my example that’s a large rate and large number of years. Picking these is something of an art, and is helped by our knowledge of the implmentation: here we know that there’s a “multiplier” effect between rates and years.
3. White box: using knowldge of the implementation to drive code coverage. Adjusting the inputs to force the code down particiular paths. For example if yoiu know that the code has a “if negative rate” conditional path, then this is a clue to include a negative rate test.