Re: black box vs glass box:
It’s a mistake to make this into an either-or issue. It touches upon the distinctions between unit, functional and acceptance tests. You want to do both – consciously separate, if possible, or consciously alone, if you can’t segregate your tests without incurring a large burden. Just as having glass box tests allows you to freely refactor and debug the implementation of individual concerns, not having them allows you to freely refactor and debug the lines along which the concerns are separated. Tests are as much a hindrance as they are an aid if they make too many assumptions about the code guts based on a very specific implementation as it existed at a very specific point in time.
The logical conclusion is that you try to have it both ways by doing glass box testing separately from black box testing, so that you have one set of tests that specifies the assumptions that are public and invariant over code refactors, and one set of tests for the guts that is understood to be volatile and having to track changes to the code. But if you don’t have the discipline to do that, or the project scope (and therefore test suite scope) is too small to warrant such a structured testing approach, then glass box testing is indeed preferable over black box testing.
3 Comments