begin quoting guy keren as of Tue, Aug 15, 2006 at 01:27:04AM +0300:
> 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]
> > > 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:
[ugly example deleted]
Oh, god, no. What a good way to miss the point. And you were so close.
"It usually just flows easily."
Show. The. Flow.
(Thus the mock-code. No parameters, no returns, no decisions. It's
not even psuedo-code. Flowcharts are too annoying in ASCII to do often.)
> and wrap this up with a little engine ("that could") that runs a list of
> (parametrized) tests.
main() {
doTest();
}
Done!
> of-course, the devil is in the little details (e.g. how to set-up, if
> some function requires a complicated setup?)
Indeed.
> > 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.
You needs a test and a way to run the test. A "framework" may be
overkill.
Eventually, you'll WANT that framework... But waving a hand and claiming
it's "simple" is ... well ... simplistic.
> 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.
Yes. Writing a framework ain't it.
You want to have some tests and a way to run 'em. Once you've convinced
people that this is a good thing in practice, you can get 'em writing
their tests first.
If you're lucky, you get to work on (or adopt) a framework out of the
gate; but lucky ain't always how it goes.
> 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.
Except the manager who wonders why 70% of your codebase isn't in the
production product.
> 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...
I think that perhaps you need to work on your evangelism skills.
--
_ |\_
\|
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
