Re: Dos and don'ts in C++ unit testing?
W. J. La Cholter wrote:
"Rune Allnor" <allnor@tele.ntnu.no> wrote in
news:1171445038.719625.156480@q2g2000cwa.googlegroups.com:
At the risk of offending the moderator, I wasn't shure whether or not
this claim was a troll in Matias' post. "Avoid testing if you can"
doesn't go very well with what seems to be a persistent main matra
in present-day textbooks?
There's hyberpole to the statement, but there's a grain of truth.
Sure you need to do some testing, but it shouldn't be a substitute for
good design, careful coding, or early formal inspection.
Testing is necessary, but not sufficient. I think that's what
we've been saying. (At least, that's what I've been saying:-).)
My own experience has been that if developers know that there is
no serious testing behind them to catch them out, they'll tend
to get a bit careless in the design, coding and inspection. The
tests aren't there to catch errors in the code, but to keep the
developers honest in the other parts. (As Dijkstra said,
testing can never show that code is correct, only that it is
incorrect. My experience has been that if you neglect good
design, careful coding or formal inspection, the code will be
incorrect in ways that show up in testing.)
Testing
should play a small role in quality from a developer's perspective.
Proper design, design reviews, and code reviews should take about 50%
of the total effort for solving a problem, with code taking roughly
30% and unit test another 10% (overhead is 10%). These are from the
SEI Personal Software Process.
They sound about right. Testing plays a small role. But an
essential role. In addition to the SEI site, I'd suggest
http://www.idinews.com/. One of the best sites I know for the
larger issues of how to write good C++ (and Java) code. A lot
there is just plain common sense, but plain common sense often
seems to be in short supply.
From an organizational level, testing plays a much more important
role. That's when things like regression testing and independent
verification and validation come into play. As a hobbyist, you'll take
on more of that role just because you'll have to wear all the hats of
an engineering shop (like it or not). The big difference is there's
less rigor because you're working on smaller projects with fewer
stakeholders.
Even for commercial projects, small projects require less
formalization of the process. If there are only two people
working in software development in your shop, a lot of what has
to be written down in a larger shop can be handled by informal,
verbal agreements. (But this shouldn't be carried too far. The
fact that you have code reviews is fine even if it is only
implicitly understood. Depending on the context, it might even
be acceptable to not write down the results of the review,
although I'm slightly sceptical. But you definitly want the
requirements you're reviewing against in black and white.)
The problem with a lot of gray-beard books is that they make sweeping
generalizations without offering data. I smacked my head several
times while reading Rapid Development: half the time reading horror
stories, half the time wanting more statistics. Without statistics,
it's programming not engineering.
Good programming is engineering. Without any concrete
measurements, it's really just wishful thinking.
The neat thing about gathering
the right metrics is that you can see whether more design time really
did result in fewer defects, whether reviews were effective, and
whether the code has a positive trend in defects discovered after unit
testing.
That's an important point. If you can't measure it, you don't
know whether what you've changed is an improvement or not.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, 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! ]