FAQ 10.03 What are some common excuses people use for not building self-testing into their objects?

graphics/new_icon.gif

Excuse: "The self-testing code is too trivial to worry about." Reality: If it's that simple, then it will be easy to write.

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.



C++ FAQs
C Programming FAQs: Frequently Asked Questions
ISBN: 0201845199
EAN: 2147483647
Year: 2005
Pages: 566
Authors: Steve Summit

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net