On Mon, 2006-08-14 at 15:02 -0700, Stewart Stremler wrote:
> begin quoting guy keren as of Tue, Aug 15, 2006 at 12:13:22AM +0300:
> [snip]
> > the first rule of writing unit tests is - don't think about it. do it.
> > the second rule of writing unit tests is - don't think about it. do it.
>
> It's easier to start this way than it is to retrofit.
>
> It's better to retrofit than to not test at all.
>
> I'm trying to figure out how to wedge in some unit tests into a
> rather large and involved C++/CORBA application. Right now, we have
> manual functional tests, some of which consist of running in the
> debugger. Bleah.
>
> > in other words - start writing _something_. you can always delete it
> > after a few hours, and even then you learned something. once you start
> > writing unit tests, it usually just flows easily, and you realize that
> > all the tests look the same.
>
> doTest() {
> setup();
> test();
> display();
> cleanup();
> }
this is not the way to write _automatic_ tests. instead, you should:
bool doTest(verbose) {
if (not setup(verbose)) {
print "test XXXX failed during setup";
return false; # don't print details - setup() will.
}
if (not test(verbose)) {
print "test XXXX failed";
return false;
}
if (not cleanup(verbose)) {
print "test XXXX failed during cleanup";
return false;
}
if (verbose) {
print "test XXXX passed";
}
return true;
}
and wrap this up with a little engine ("that could") that runs a list of
(parametrized) tests.
of-course, the devil is in the little details (e.g. how to set-up, if
some function requires a complicated setup?)
> > in having to chose between having an incomplete set of tests, or having
> > nothing because you "couldn't figure out how to best do it" - always
> > chose the first option.
>
> A framework is nice, but lack of same shouldn't keep one from writing
> a test -- although it often does. :(
a framework is simple to write. lack of it should encourage you to write
something quick and evolve it as your tests evolve.
the idea with automatic tests, is that in order to convince people (and
yourself) that they are useful, you need to be able to show something up
very quickly. after you got something up and running, you'll enhance it
as you go. ofcourse, if you're writing the tests along with writing the
system, you have more freedom to invest more time in writing the tests -
you don't need to convince anyone after-the-fact.
--guy,
who had to work for a year in tests programming and public relations in
order to convince his company that automatic tests are not "nice to
have", but rather "we can't live without them". the tests started
working after a week - and keep being enhanced all the time...
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
