should unit tests be black box tests or white box tests?

Question

Say I have three methods, all very similar but with different input types:

void printLargestNumber(int a, int b) { ... }
void printLargestNumber(double a, double b) { ... }
void printLargestNumber(String numberAsString, String numberAsString) { ... }

All three use the same underlying logic. For example: maybe the double version is the only one that compares numbers, and the other two just convert their inputs to double.

We could imagine a few different unit tests: first input is larger, second is larger, both inputs are negative, etc.

My Question

Should all three methods have the full set of tests (black box since we don't assume the core implementation is the same)

or

Should only the double version be tested heavily and the other two tested lightly to verify parameter conversion (white box testing since we know they share the same implementation and it's already been tested in the double tests)?

Answer 1

If all of those methods are public, i.e. callable by the outside world, I'd definitely test all of them with a full set of tests. One good reason is that white-box tests are more brittle than black-box tests; if the implementation changes the public contract might change for some of those methods.

Answer 2

It depends.

Do you think the implementation is likely to change? If so then go with black box testing.

If you can guarantee that the implementation won't change go with white box. However, the chances of you being able to guarantee this aren't 100%.

You could compromise and do some of the black box tests, particularly around the boundary conditions. However, writing the tests should be easy - so there's no excuse from that point of view for not doing full black box testing. The only limiting factor is the time it takes to run the tests.

Perhaps you should investigate the possibility of running the tests in parallel.

Answer 3

There are a set of tests that explicitly exercise the public interfaces. I would treat those as black-box tests.

There are a second set of tests that could be seen as looking at the corner cases of the implementation. This is white box testing and surely has a place in a Unit test. You can't know the interesting paths without some white-box implementation knowledge. I would pay particular attention to the String case, because the interface allows for strings that may not convert cleanly to doubles, that push the boundaries of precision etc.

Would I cut a few corners in the integer case? I know I pushed the paths in the double case, probably shouldn't but might well under time pressure.