Wed, 19 Feb 2003
Lots of tests up front
On the
test-driven development group, I asked if people had
experience switching from a process where programmers
implemented all the unit tests after the code to one where they
implemented all the unit tests before any of the code. That
replaces Big
Design Up Front with Big Test Up Front (sort of). I speculated it might
be a reasonable intermediate step in organizational change.
C. Keith Ray
writes the following:
Writing a whole lot of tests, and then writing the code to pass the tests
has allowed my coworkers to create a whole lot of redundant code. In their
case, they copy-paste-modified a bunch of tests, and then copy-paste-modify
a bunch of code.
They didn't have a refactor step after getting each test to pass.
With a refactor step between each test, they could have noticed that the
second piece of code to pass the test was almost identical to the previous
piece of code, and thought about making a parameterized object instead of
duplicating a method and changing one line.
Darach Ennis writes:
When I started out in the big bad world after university I joined
an organization which followed a 'One Shot Deal' development
lifecycle. SEI CMM with the V Model to be precise...
At the time I didn't know any better so I gave writing my test
stories up front a shot when writing requirements etc..
Ultimately whenever I started coding, after a long train of documents
and reviews, I quickly found the documented tests becoming less and
less relevant as my assumptions were always incomplete, innacurate
and sometimes irrelevant.
I spent more time re-writing documents than coding or contributing
anything really useful. [...] My question would be whether the
frustration and wasted work was better or worse with tests than
it would have been with design documents. - bem
For me, test first implies one test or task at a time. Writing 10 or
20 tests without feedback from code is presumptuous and may prevent
the minimal amount of code required to satisfy a stories acceptance
criteria from emerging.[...]
[A company] might stand to gain a lot more if they can objectively gauge
differences in methodologies rather than provide a 'migratory'
testing approach for them to ease them into test-first. Sometimes
its better just to roll up ones sleeves and give it a shot.
That's how I started out with TFD/TDD. One day I just decided to give
it a shot. It took a few weeks before TFD/TDD clicked. It took
another few months before I started to become proficient.
## Posted at 16:55 in category /testing
[permalink]
[top]
Fixtures as controllers - credit where it's due
Earlier,
I speculated that FIT fixtures might be controllers, as in
model-view-controllers. I learn that Rob Mee speculated the same
speculation in exactly the talk I saw him give. I wish I could say
that great minds think alike, but it's actually that my mind
forgets where it learned something.
## Posted at 16:16 in category /testing
[permalink]
[top]
|
