Re: Dos and don'ts in C++ unit testing?
Mathias Gaunard wrote:
On Feb 12, 7:03 pm, "Rune Allnor" <all...@tele.ntnu.no> wrote:
As is said in most books (e.g. "Pragmatic programmer"), "code a
little, test a lot."
I would actually advise the opposite.
Yeh, that's what customers are there for, to do the testing.
Regretfully, a lot of my suppliers seem to take the same
attitude.
Testing is a long, tiring, boring, and imperfect process. You should
try to avoid it whenever you can.
You need it, in order to validate your process. Obviously, if
the tests find an error, there's something wrong in your process
upstream, which you'll want to address. But in my experience,
if you skip on the testing, things will degenerate upstream, and
you'll end up with very bad code.
Note that a lot of books seem to neglect this point. You don't
test to find errors in the code; you test to ensure that your
process is working.
For that, the best is to have as much compile-time checks as
possible. You should try to reach the point where if it
compiles, then the code is almost certainly correct.
That's certainly a laudable goal, but it isn't nearly 100%
possible. What the compiler can't catch, of course, code review
should. But without the tests to back things up, code review
(and the addition of compile time checks) tends to become
watered down; most developers seem to find it more fun to add
new features to their own code than to review other people's
code.
Unit tests are important for regression testing, as well. Full
scale code reviews, while necessary for initial development and
major reworks, are a bit expensive for one line bug fixes---in
such cases, an extensive set of unit tests will ensure with a
fair degree of assurance that you didn't accidentally break
anything else. (As a general rule, you never correct an error
in the actual code until you have a unit test which reveals it.
Otherwise, how do you know that you've really corrected it.)
Another important point of unit tests is that they exercise
exactly one thing at a time. So if a unit test fails, you know
where to look in the sources. Not as much as if a code reviewer
says that I forgot to initialize variable x in line y of file z,
but still, it's a lot more precise than if a customer calls and
says he's getting random core dumps twice a day.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientie objet/
Beratung in objektorientierter Datenverarbeitung
9 place Simard, 78210 St.-Cyr-l'Icole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]