Re^4: Neither system testing nor user acceptance testing is the repeat of unit testing (OT)

Correct interface design and mocking will allow you to black-box all your unit-tests. That's a big statement, but I'm willing to be proven wrong. (Yes, that's a challenge.)

I basically agree, with a moderate number of caveats :-)

Legacy code. I'm going to carry on adding white-box unit tests to test free code that's not been designed with testing in mind.
Code clarity. Sometimes I think the code remains clearer with a couple of private methods than it does by factoring out a separate support class. If I think that I'll quite happily write white box tests if I need to tweak them.
Can TDD ever be black box? Since the next test is driven both by the spec and by your knowledge of the implementation you can argue that it's always white box. The kind of unit tests that TDD produce are very different from the sort of unit tests a pure specification based approach might take (see discussion on the TDD list for example).

Comment on Re^4: Neither system testing nor user acceptance testing is the repeat of unit testing (OT)

Replies are listed 'Best First'.
Re^5: Neither system testing nor user acceptance testing is the repeat of unit testing (OT) by tirwhan (Abbot) on Oct 25, 2005 at 10:07 UTC
I think TDD is only done correctly if unit tests are black box. You write your tests and thereby define your interface, regardless of the implementation behind it. Once you get to the refactoring stage you (may) change your implementation to make your code better organized\|more efficient\|less redundant\|etc. Your refactoring succeeds if you manage to change your implementation without breaking a test. If you then have code that's not being tested, you have one of two cases Your tests don't accurately describe your interface, because you forgot to test for an outcome that should be part of your spec. The untested code should be removed because it produces an outcome not included in the spec (because ideally your tests are the most thorough description of the spec) In the case of 1. you need to add a test, but you still want to test against the module interface, not against the particular implementation. This is a corner case where you're actually finding a better interface by coincidence while refactoring. If you're writing your tests correctly it shouldn't happen (though IRL it does). I do agree that it takes a special sort of mindset to properly separate your test-writing brain from your implementing brain, so that's a practical problem for all but the schizophrenics among us :-).	[reply]
Re^5: Neither system testing nor user acceptance testing is the repeat of unit testing (OT) by dragonchild (Archbishop) on Oct 25, 2005 at 13:53 UTC
In the case of retrofitting tests to code, one might divine the specification from the implementation. I will be doing this for PDF::Template over the next few weeks. However, the tests should still be testing the interface, not the code. I fully expect to find and fix several bugs over the next few weeks by thinking of things this way. In the case of private methods ... that's an interesting point. Now, you have a private interface that you're testing against. You write tests against the private interface, then tests against the public interface. Just because you didn't publish the private interface doesn't mean it's not a black-box test. The tests for the private method are against the privately-published interface of the private method. TDD tests shouldn't be driven by the implementation. Look at Pugs as a perfect example of this. Half the test-writers can't read Haskell to save their life, but it's still TDD. My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]


Perl Monk, Perl Meditation
	PerlMonks