zaimoni
2/23/2008 2:01:00 AM
On 2008-02-22 08:09:22, Patric Mueller <bhaak@bigfoot.com> wrote:
> Kenneth 'Bessarion' Boyd wrote:
> > On 2008-02-21 15:35:49, Patric Mueller wrote:
> >
> >> Gerry Quinn wrote:
> >> > In article 34b3f59e0b9b@k2g2000hse.googlegroups.com>, torespondisfutile@hotmail.com
> >
> >> > This test would have been much harder to write in advance.
> >>
> >> You shouldn't write your tests before coding but during coding.
> >
> > Depends. Gerry was describing a case where the behavior wasn't well-defined
> > beforehand; it wasn't even *possible* to write the unit test before.
>
> I think we have here a disagreement about the granularity of the unit
> test.
Yes. I allow for non-atomic tests with subtests, tests that depend on other
tests working to even be valid, and so on.
> ....
> A unit test should be simple. The moment you have to start debugging a
> unit test it is too complicated.
That is a useless definition in my practice: I intentionally do two or three
debugging/proofreading passes on *all* code as I write them. If I'm in a
personally non-fluent programming language like Python, Java, or ActionScript I
bounce this up further.
One line, one statement is not too simple to escape this cultivated habit of
immediate debugging.
> > If the intended behavior is well-defined, standard Extreme Programming practice
> > is to write the unit tests first.
>
> Standard XP practice is to write the unit tests first *period*
True, I was restricting to when standard XP practice was *possible*. However,
XP degrades quite gracefully when not all requirements are possible; you just
use what you can.