Re: Dos and don'ts in C++ unit testing?
W. J. La Cholter wrote:
"James Kanze" <james.kanze@gmail.com> wrote in
news:1171447862.583583.126700@s48g2000cws.googlegroups.com:
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.
Actually, you test to verify that your software meets the
requirements.
Yes and no. If your process is working, your software will meet
the requirements, whether you test it or not. And of course,
it's not unusual that some requirements aren't really testable.
True quality comes mostly from good design, careful coding and
rigorous review. Testing really just confirms (or inconfirms)
that these are doing their job.
If it doesn't meet the requirements, then there are
errors in the code.
And if there are errors in the code, something upstream in the
process isn't working as well as it should.
While unit testing, you test each case. If
something fails, you fix it. If after testing, you discover a high
defect rate, e.g., a metric of defects/KLOC, then there could be a
problem with the process or application of the process. You use
metrics to determine if your process works.
To a degree. The basic principle is based on metrics. A
reasonable metric for defects/KLOC would be about 1 defect/100
KLOC, going into integration tests. (For critical software, of
course, you expect less.) For smaller projects (or
sub-projects), that means that even a single defect has passed
the limit; the metric has become anything more than 0 defects.
Process validation is an entirely different meta-activity conducted
outside the scope of solving the problem at hand. You use that to
figure out if you're spending too much or too little time on an
activity or whether you're even doing the activity right. That should
be done during a post-mortem phase, perhaps immediately following unit
test.
In theory, yes. Process validation is certainly outside the
scope of solving the problem at hand. But it's activity is
triggered and determined by measures from the project at hand.
I've found that at least on smaller projects, it's worth
checking after every error detected in tests, whether there was
something you could have done upstream to avoid it: better code
review, better specification of the requirements, etc. Perhaps
the process hasn't been as good as it should be in the places
I've worked, but in almost every case, a defect detected in
testing was a symptom of something we should have done
differently upstream.
--
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! ]