Excuse: "The self-testing code is too complex." Reality: If it's complex, then it's worth the trouble no matter how long it takes. Excuse: "I can't afford the time to write the self-testing code." Reality: You haven't done your job until your class's internals are documented. Excuse: "Calling the self-testing code will consume too much CPU." Reality: That's bogus. You can remove 100% of the runtime overhead by using #ifdef. Besides, if it's going to consume a lot of CPU, then either the self-testing checks are sophisticated or the class is very important and commonly used, both of which are arguments in favor of this approach, not against it. Excuse: "The self-testing code might contain bugs, so the technique would be worthless." Reality: Also bogus. If you're not sure that you can express the promise (postcondition) and invariant of your own class correctly, then those promises and invariants should be tested. The self-testing approach provides this for free since it simultaneously tests the class's documentation (its promises and invariants) at the same time as it tests the class's implementation. |