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

To clarify one point, if you create a private API to allow tests of private functions, I consider that to be white-box testing. Those are tests that cover internal aspects of behaviour that nobody else should rely on, which might change in future versions.

I would consider this black-box testing of the private API. The API you expose to the world and the API you expose to your code are rarely going to be identical. Of course, you should test the complete API, not just the API you expose to the world. If the rest of the world considers this white-box, then, in my public API, I'll consider this white-box as well. What it maps to in my personal implementation of this spec is irrelevant. :-)

My criteria for good software:

Does it work?
Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Comment on Re^2: (OT) Black- vs. white-box testing

Replies are listed 'Best First'.
Re^3: (OT) Black- vs. white-box testing by tilly (Archbishop) on Oct 26, 2005 at 17:56 UTC
The reason why I call that white-box testing is that the private API is often explicitly designed to shine a white light on otherwise dark corners of the implementation. For instance in the regex example, you might have a flag that is available telling you which version was actually run. That allows something which should be invisible (whether you've turned on the optimization) to be tested.	[reply]