Re: unit testing advice

David A. Black wrote:
> Hi --
> 
> On Sun, 3 Aug 2008, Shadowfirebird wrote:
> 
>> I certainly "get" the idea that it's better to write the tests first.
>> Unfortunately my dinosaur brain needed to write some code to prove
>> that my class model was workable...!
> 
> I often have to bootstrap myself into an application by getting
> something running before I can get my brain into test mode. Certainly
> with something like Rails, there's a lot to do before any tests are
> written, since you can't write unit tests before you know what your
> models are (and generating the model so conveniently writes the test
> file for you :-)

Isn't the idea of TDD and BDD that you discover what classes and method 
are needed by writing the tests first?  So there *should* be no model in 
place prior to writing the test; the initial failure of the test is what 
drive the creation of the model.


> 
> One thing to remember is that TDD is about development, and that not
> all instances of entering code on a keyboard are development. And
> we've all, I believe, learned an absolute ton from exploration and
> experimentation that wasn't part of the process of ongoing application
> development. It's important not to feel like you're being
> unprofessional or sloppy if you happen to want to try out some code in
> a file, or in irb, and you don't write a test for it.
> 
> In fact, one question that has come to intrigue me recently is the
> question of whether there are any active programmers who have
> literally written code test-first from the time they first learned how
> to program onward. I suspect the answer is no -- and if that's the
> case, it means that there is no evidence for the position that it's
> always, automatically bad to write code without a test. 


Has anyone ever seen a Learn To Program or Learn Language Blub book that 
did TDD?  I doubt such a thing exists.  Instead, people are shown code, 
encouraged to write code, then (in so many words) told that what they 
were  shown and told is not the right way to code.   On the other hand, 
having  a unit test for the 1-liner helloworld.rb seems massively goofy.

A more useful view is that TDD and company  are for code you plan to 
keep and maintain, and if you find supposedly transitory code lingering 
a bit too long you need to consider re-writing via TDD or retro-fitting 
tests.  (And even that should be tempered by the size of the code in 
question. )

> That's not
> meant to be a counterargument to the idea that testing is important
> and a good practice. I do wonder whether things get a bit too
> doctrinaire at times, though.

What I've often heard is that folks (such as  myself) will hack out a 
running version of something as a means of exploratory coding; it's like 
doing sketches prior to starting The Big Fresco.  Then (so some claim), 
that code is chucked and actual TDD begins: tests, failure, code to make 
the tests pass.

In reality I think most exploratory coders will salvage the nicer parts 
of the code and tack on unit tests, then move forward with TDD.  There 
may be some bias at play, where the time invested in creating that 
initial code colors how one determines its quality.

> 
>> What I'm seeing quite clearly now, is that the next best thing is
>> writing the tests while *pretending* that you haven't written the code
>> yet.
>>
>> Because the tests should be based on what the code is *supposed* to
>> do, not what it does.  Look at the code when you want to know what it
>> does; but when you want to know what it's supposed to do, look inside
>> your head.
>>
>> I suppose you are all going to say that the tests should show what the
>> code is supposed to do?  I really like that idea...
> 
> I don't think you have to decide it's one thing or the other. If you
> can write tests after you write code, *and* if you feel certain that
> the code is as good as it would have been if you had written the tests
> first (not all first, but iteratively), that's fine. It's that second
> clause that's the issue, though. A lot of people find that writing
> tests first helps them get in the "zone" of thinking about *exactly*
> what their code is supposed to do, in a very focused way. So it
> becomes part of the process of writing the program, not just a way to
> put protective armour and/or documentation around it later.

That sounds about right.  Testing is not the goal; robust, accurate, 
maintainable code is the goal.

-- 
James Britt

www.happycamperstudios.com   - Wicked Cool Coding
www.jamesbritt.com           - Playing with Better Toys
www.ruby-doc.org             - Ruby Help & Documentation
www.rubystuff.com            - The Ruby Store for Ruby Stuff