Re: (OT) Black- vs. white-box testing

[blazar]

I'm not terribly familiar with any of the terms above. But of course I've heard and used them too, more or less naively, and I think that my intuition/perception/understanding if not perfect should be close to the accepted common sense about them...

Now the issue about Black-box vs. White-box testing is interesting, and I must say that I hadn't even heard the latter expression before. I'm not even really sure if I understand what it should be... could you please explain to us less experienced programmers?

I mean: I see how one can test an implementation against a specification of an interface. What are "tests written against the implementation"?

[tirwhan]

Tests written against an implementation rely on internals of the code which are not part of the interface. As a very simple example, say you have a module which takes input A and B, merges that data into a data structure C, then performs some calculations on it and gives you back D. If you were testing against the interface(black-box), you'd write tests which put in A and B and check whether you get the correct D out. If you were to write a test against the implementation(white-box), you'd also check whether C conforms to your expectations or whether the algorithm to turn C into D works a particular way. If later the module writer decides to change the implementation and do without the intermediate C (or change it in some way), the test breaks.

[blazar]

Then I agree with OP that such a practice (white-box tests) are, in general, a CodeSmell. If one considered the data structure C to be important enough to warrant a test, then he should refactor, or enrich the interface (spec) so as to include it too.

[TStanley]

Just as a simple suggestion, you might want to pick up a book called The Pragmatic Programmer. It will easily answer all those questions, and make you come up with more.

[robharper]

I mean: I see how one can test an implementation against a specification of an interface. What are "tests written against the implementation"?

One of the usual techniques is to examine the code as written and find all the decision points, which will lead to discovering all the possible paths of execution through the code. Tests can then be written to "exercise" each of these possible paths to ensure that every line of code behaves as expected.

It is arguable how often this is useful and, of course, refactoring is likely to render some of these tests obsolete.