On Nov 30, 2006, at 6:31 PM, Taylor S. wrote:
Rails went from fun ActiveRecord magic tricks to a world of ‘TEST
FAILED.’
I’m a newbie to TDD, and ran into it slightly BEFORE I hooked up with
Rails. In my “real job”, automated testing requirements came in without
the rest of the Agile approach in place, and there, it has been a real
drag to get into TDD. I was lucky to have a member of my team who was
not new to it, and he started feeding me the zen of TDD in the right
way. Not “we will now write tests for everything in the world before we
write the application”.
The job before us involved creating both a new XML based GUI layer and
also the glue and support code needed to hook that to an existing set of
“middleware” (this is phone UI stuff). I was doing the glue/support
code, and he was in charge of writing the XML stuff. He helped me
realize that the easy way for him to communicate just what he needed
from my part, was to write a test. He would send me an email something
to the effect of “I just added a test for BLAH”, and then I would go off
and write some stuff that makes his test pass, then he would hook that
up to his XML and goodness would happen.
Every now and then he would add to or change a test and say “I just
realized I also needed fooBah, so I just broke the test”, and I would go
in and instantly see from his test exactly what I needed to add to my
code. It has been a delightful way to communicate specific requirements
for our interface.
The key here is that we didn’t write “all the tests” and then write “all
the code”. Instead, we developed the app one piece at a time and used
the tests as a way to communicate what the top layer needed from the
lower layer.
Now we are into the last phase of the project where we are doing
profiling and looking for things to optimize. Taking specific large
hunks of my code and rewriting it is not a scary thing, even with the
release just days away, because I can and do run all of the tests after
I make both big and small changes, and when all the tests pass,
everything just works. Magic.
So I would say that you need to look at TDD in Rails more in line with
the Agile way of developing an app, quite like the process that the
“Dave’s” lay out in the Agile Rails book. The stuff about showing the
client and the client says “wow, that’s great, but what about yadda
yadda”, and that takes us to the next part of the development. Instead
of designing the whole thing down to the last iota of specificity before
you start, you just kind of feel your way through it, and you do the
tests as you go. Any you and the “business people” play with it a bit
and you notice something and you say, “hey, I shouldn’t be able to enter
so and so in this field” - translation “write a test that fails if the
user can successfully enter so and so in the field”, run it to verify
that it is breaking, then add the code that makes it pass.
It isn’t about spending 40 days and 40 nights writing tests before you
start on the real app. It’s just a different way of designing and
developing a product, that includes creating a “proof of the pudding” as
you go. Five minutes thinking about the state of the app and how to
take it to the next (tiny) level, followed by five minutes of writing a
few tests and five minutes of making the tests pass, and viola, we’ve
achieved a new level with our app, and we know it works right.
And because of the TDD approach, every little hunk of the project works
perfectly (within the limits of the requirements we have defined – i.e.
the tests we have written) as we go, so there just isn’t any of the old
way of “OK, it’s feature complete – in a few months we should have some
of it actually working right”.
jp
