Re: Dos and don'ts in C++ unit testing?
Roy Smith wrote:
"James Kanze" <james.kanze@gmail.com> wrote:
I'd say almost the opposite. If the functions don't depend on
one another in some way, what are they doing in the same class?
They all operate on the same data?
Maybe. My point is just that totally unrelated functions don't
belong in the same class, and that related functions can't
necessarily be tested separatedly.
And until you have some accessors, you cannot test the
constructor. For most of my value classes, about all that's
left is assignment.
As PC would say, "Not true!". My first test case will typically be just to
see that I can construct an object. It's the "smoke test" of a new class.
To get to the point where you can compile and run:
test_fooConstructor() {
foo f;
}
you need to do all of (details will depend on your environment):
1) Create a .h file and declare the class in it
2) Create a .cpp file and define the constructor
3) Teach your build system (and your version control system) that both
files exist
4) Create a test case
5) Teach your build system (and your version control system) about the new
test case
6) Document what the class does (which might mean teaching your doc
generation system that the class exists)
That sounds a bit backwards. Before I'll even write "class Toto
{};", I'll have documented the role and the responsibilities of
the class. Once the documentation of the class is finished (the
entire .hh file, more or less), I'll attack the implementation.
Not before.
Most of this is pretty trivial, but it's enough stuff that there's plenty
of room to do something wrong, even if it's only making a typo.
Certainly. On the other hand, is the chance of getting it wrong
high enough to justify special tests just for this. (Or maybe I
just don't consider it "tests"; even if I don't test, I have to
go through all of the above, except for 4.)
You've got
to do all this stuff anyway, so you might as well get it all out of the way
now.
I'd recommend writing the .hh and the .cc files before trying to
compile the code, too. As well as introducing the files to the
build system. Depending on how version control is used, it may
or may not be relevant---I can think of organizations where you
can't check code in until it passes code review, which means
that it must be complete (including tests); in other
organizations, everything is under version control, from the
moment you decide on the name of the file. (I sort of prefer
the latter, but both can be made to work.)
I see no strong reason for or against writing the first test
case before finishing all of the .cc files, or leaving them to
the end. It's a question of personal preference. In the end,
you have a deliverable; that deliverable consists of all of the
sources and all of the test code, and possibly some
documentation (although in my experience, very little
documentation is necessary in addition to that which defines the
deliverable, and which, obviously, must be done before starting
on the deliverable). The internal order you choose to use to
develope the deliverable really doesn't matter. Use what works
for you.
You might even discover that it doesn't compile (or link, or run).
With so little code actually written, it should be trivial to figure out
what went wrong at this point!
Generally, if the deliverable is small enough, it should be
trivial to figure out what went wrong whenever the unit test
reveals an error. (This is one of the main reasons why I find
debuggers of limited use. But again, used on a unit test, if it
works for you, why 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! ]