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?