Re: A simple unit test framework
Ian Collins wrote:
Pete Becker wrote:
Ian Collins wrote:
Pete Becker wrote:
nw wrote:
I previously asked for suggestions on teaching testing in C++. Based
on some of the replies I received I decided that best way to proceed
would be to teach the students how they might write their own unit
test framework, and then in a lab session see if I can get them to
write their own. To give them an example I've created the following
UTF class (with a simple test program following). I would welcome and
suggestions on how anybody here feels this could be improved:
A fool with a tool is still a fool. The challenge in testing is not test
management, but designing test cases to cover the possible failures in
the code under test. That's something that most developers don't do
well, because their focus is on getting the code to run.
Unless the test are written first!
You can't do coverage analysis or any other form of white-box testing on
code that hasn't been written.
If you code test first (practice Test Driven Design/Development), you
don't have to do coverage analysis because your code has been written to
pass the tests.
No, that's not what coverage analysis means. See my other message.
If code isn't required to pass a test, it simply
doesn't get written. Done correctly, TDD will give you full test
coverage for free.
Nope. Test driven design cannot account for the possibility that a
function will use an internal buffer that holds N bytes, and has to
handle the edges of that buffer correctly. The specification says
nothing about N, just what output has to result from what input. What
are the chances that input data chosen from the specification will just
happen to be the right length to hit that off by one error? If you know
what N is, you can test N-1, N, and N+1 input bytes, with a much higher
chance of hitting bad code.
There is a big difference between a
tester's minset and a develper's mindset, and it's very hard for one
person to do both.
I don't deny that. Always let testers write the black box product
acceptance tests. That way you get the interpretation of two differing
groups on the product requirements.
Good testers do far more than write black box tests (boring) and run
test suites (even more boring, and mechanical). Good testers know how to
write tests that finds bugs, and once the code has been fixed so that it
passes all the tests, they start over again.
--
-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)