[ruby-talk:25772] Re: rubyUnit, et. al.

Albert Wagner wrote:
> If I had to name my modus operandi, it would probably be called "sculpting"
> (as in wax or clay, NOT rock).  I start first with a really sloppy script,
> written as fast as possible; a sort of "proof of concept" to myself that what
> I want to do is even possible. Classes seem to split, spawn, morph, disappear
> and reappear with great rapidity.  I am constantly refactoring.  Only
> gradually does the design begin to settle down and firm up to the point that
> unit testing would be feasible.

Someone mentioned earlier that the open scope of classes meant that it
was easy for him/her to work _completely_ inside the test-code and only
move it over to the production code once the tests ran.

I don't think you need to think of unittests as any more static than
your main code. I'd expect the testcode to change and morph along with
the rest of the code. This is one of the purposes of unittesting. By
keeping the change-increments small and always keeping the tests
running, you can do many changes while still being confident that
complex bugs hasn't crept into existing code, nor existing functionality
been broken. Reading what Kent Beck says in his books, a fitting
extension of your metaphor would be that unittests are the water that
keeps your clay flexible and mallable, and avoids it drying, cracking
and turning into dust. :-)


> I am curious about how others work;  And how unit testing is really used:
> as a predefinition of specs or tacked on after-the-fact to convince others
> that you are PC (Politically Correct).

Unittests as in XP aren't a predefinition of specs, but something that
grows in parallel with the main code. Ideally, you'll write the unittest
for a method before writing the method, but this doesn't extend to the
project at large.

In "hobby-projects" I use unittests for wrapping up and collecting small
tests that check functionality of smaller and partial methods, and for
testing functionality. I don't necessarily write the tests first. I'm
somewhat lazy, so I'm more motivated for writing tests for methods which
have a clear "given-input-yields-expected-output" way of working. I'll
often write tests which are more "functional tests" rather than
unittests. (F.ex. testing output on a higher level, such as testing that
module writes a correct XML document, not testing each output method in
separation.)

Even if you only add tests afterwards (given you don't fall victim to
laziness), you get the most important benifit: Regression test
possibilities for anyone who would want to refactor and change
something.
	You'll lose some of the different perspective that writing tests can
give, since it helps you focus on interfaces earlier, while you're still
not "brainwashed" by the chosen implementation.

But if you ever feel "wrong" about writing unittests after the fact,
keep in mind that it originally came about as part of software
verification efforts, where unittest were written after _all_ the code
was done. 

-- 
<[ Kent Dahl ]>================<[ http://www.stud.ntnu.no/~kentda/ ]>
  )____(stud.techn.;ind..data)||(softwareDeveloper.at(Trustix))_( 
 /"Opinions expressed are mine and not those of my Employer,      "\
( "the University, my girlfriend, stray cats, banana fruitflies,  " )
 \"nor the frontal lobe of my left cerebral hemisphere.           "/