Complete Coverage

Short one here, mainly because this should not need much to get the point across. This post is about covering your code with tests.

There are many categories of tests, e.g., unit, functional, system, acceptance. Each of these are requisite to be on the Right Path to the Right System. If you want to know more about these types of tests, let me know (@Rjae) and I'll queue a future post. The point of the combination of these types is Test Coverage - or the degree to which the domain, range, and agility of your system is tested and thus proven to a level that produces the Right System.

There are many techniques of developing tests, e.g., black box, white box. While it is widely accepted that categories of tests are NOT mutually exclusive and in fact MUST be combined for complete coverage, the techniques used to develop tests are generally considered either or...but not both. I.e., "I'm a white-box tester.", "I'm a black-box tester.". After decades of developing tests if there is one thing I have learned it is this: you cannot do without one or the other. As with types of tests, the types of techniques MUST be combined for complete coverage.

White Box Testing is: ensuring a complete enough percentage of a system's code paths are traversed.

Black Box Testing is: ensuring a complete enough percentage of a system's data range is processed.

Now, this materializes as intentionally knowing and testing the internals of methods - and intentionally knowing and testing the exports of classes (public methods).

I boiled this down to the core because in doing so I hope to reveal how silly it is to choose one testing technique over the other. Doing so amounts to saying: "I test my code, but not my data." or "I test my data, but not my code.". Of course we must do both!

I hope with this post you are motivated to get after complete coverage of your system - if you do you are doing one of the things that will keep your software project on the Right Path.