Re: Dos and don'ts in C++ unit testing?
Phlip wrote:
James Kanze wrote:
Take all the time you spend, after coding, in debugging.
Transfer it to time spent, before coding, writing test cases.
Design would be more useful.
That's why test-first is a design technique. It is useful.
Except that you can't write the tests until you've done at least
the requirements specifications, and you can't capture many
important features of the design in the tests. Tests do not
replace design.
You will have lots of time left over.
How does writing the tests before you write the code, rather
than later, change the amount of time spent in debugging.
Because your designs will strongly resist bugs, you will have
fewer of them, and you will have much more time left to devote
to the remaining ones.
Do you have any concrete measurements to back this up. I don't
see any relationship. Tests have nothing to do with design, per
se, and most of the criteria for good design aren't testable.
I've written a lot of robust code which has been delivered
without a single test (although that's not a good policy
either), but I've never seen any robust code which has been well
designed.
If you don't design your code, you're going to spend a lot
of time in debugging. If you do, you're going to spend a
lot less. Regardless of when you write the tests.
So, by that reasoning, if we _do_ design code before writing
it, and if we discover another design technique which happens
to use test cases, then we will spend even less time
debugging.
There are those who practice Test-Driven Development - even in
advanced networky C++ - and never feel the need to invoke a
debugger. That's not the same thing as never debugging, but
it's very close.
I don't use a debugger myself. And unit tests certainly
contribute to this. But they don't replace good design, which
is essential as well.
(The specific issue with a debugger is that, for each manual
experiment you perform with it, you could instead have written
a new test case. So if your code is already completely
test-ready - because it's well designed - then you have almost
no reason to invoke a debugger.)
The specific issue with a debugger is that you can't use it
until you have a fully linked executable. By which time, if you
have good design and good code review, there are very, very few
errors left anyway. And of course, if you've done your design
work, you know what input produces what output, and which steps
the code goes through for each possible input. Which means that
you can usually find the error just by studying the sources,
knowing the input and the actual output, in less time than it
takes to fire up a debugger.
There are those who call this "test-driven development".
Write failing tests, then write code to pass the tests.
This implies you (generally) only write new code if you can
get a test to fail, first, because it's not there.
Which neglects the entire problem of specification.
I also did not mention you use a keyboard. Yes, you also use a keyboard
while doing this technique. And a steno chair, mouse, etc.
Obviously. And? Even the worst hackers I know use a keyboard.
"test-driven development" is one of those catch words, invented
when there are no other good arguments. The very first thing
you have to do when developing software is to decide what it has
to do---what the requirements specifications are. Then, design.
Only once you've done these two steps can you start writing
code.
And that is exactly why another of these "catch words" is "story test" - a
test written for your business-liaison to review, to help convert verbal
requirements into mechanical specifications.
Except that my business-liaison is usually incapable of
understanding what my programs should do. At least at a level
that is "testable". On the other hand, my business-liaison does
know that he doesn't what the server to core dump (even if he
doesn't know what a core dump is), and there's no way to be sure
that it won't by testing.
And of course, the requirements almost always contain aspects
which are *not* testable. Where I work, for example, it is a
requirement for almost everything I write that it be thread safe
(impossible to test), and understandable by others (even more
impossible to test).
Right. Things that are impossible to test are generally "computer science".
Example: Does a complex algorithm fit within an OlogN performance profile?
Putting the OlogN part into a test case would be worse than useless.
Most threading problems aren't testable either.
However, once you pick an algorithm, its specification will
lead to numerous small details, each perfectly ripe for
testing.
In sum, once you've got a good design, it should be possible to
develop useful unit tests. Totally agreed. Once you've got a
good design, it's also possible to code the functions
immediately. Whether you code the unit tests or the functions
first is totally irrelevant. And if you're a careful coder, you
may just discover that the unit tests work first go. I usually
feel that I've been unnecessarily careless if they don't.
--
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! ]