On 11/20/06, Brian H. [email protected] wrote:
“Test-first development seems a bit easier in some languages like Ruby. In
Java this seems a bit less popular - your tests won’t compile if the classes
under test do not exist yet, so TFD is a bit inelegant at the outset.”
Exactly. That’s part of test-driven development. Tests not compiling is
Yeah but the stack-trace bomb is a pretty inelegant part of failing. I
like it to gracefully fail with error messages, and not play havoc with
intellisense in my IDE either, making my source code look like a letter
a six-year-old typed out with their nose.
But thats just a statically-typed thing that makes Test-first
a bit kludgy to start with. However it is a significant part of why TFD
not done. For continuous integration systems, I would prefer if tests
failed during the unit-test phase and not during code compilation.
(okay the fact that I checked in uncompiling code into a CI system is
a fudged example, but you can see where I am coming from). Still
you can see that this is a pretty Java (presumably any other statically
typed/or compiled language problem too) test idiosyncrasy, a Ruby
unit test would fail during the test phase of CI just where it should.
TFD is way more powerful than Test-second-Design. Both are good, but
you will get more churn in Test-second-Design. Over time Test-second
design forces an implementation that you would have gotten to earlier
with TFD. TFD is better at promoting KISS as it makes your tests easier
to implement. So TFD enforces better habits.
I have found that Test Driven Development (any kind) makes me think
differently about the code under development. If I am stuck in a coding
problem (paralyzed by implementation choices) I can go into unit test
mode and it often steers me through this process.
Also TDD is the mongoose to the snake of obtuse design. If it is hard
to unit test an obscure object hierarchy, then you have to give up
or unravel the implementation. Your colleagues would appreciate the
latter a lot. Java development contains a lot more fashionably-obtuse
hierarchies than is healthy.
You will like rcov. It’s quite handy although not perfect. Combine that with
ZenTest and you have no excuse NOT to do unit testing.
I loved clover, if its anything close, I am sold. When you use a good
tool to patch up a blind spot in your unit test harness and in doing so,
a bug, you are sold on it forever. Boosting coverage is a great way to
idle developer cycles or get new team members familiar with the code
Then you had month after grueling month of fixing bugs that were found
by the test group. This time, the testing/bug fixing stage had more to
do with working out the poorly worded parts of the Spec, rather than
fixing malfunctioning code. The code wasn’t perfect (because the tests
weren’t perfect), but the difference was night and day.
Note: Unit Testing can’t find all bugs, even at 100% coverage. What it
do is cover you for significant bugs that are tedious to test for.