I’m listening to the latest .Net Rocks show with Rocky Lhotka, and I’m saddened that he gets it so wrong about TDD. DNR’s last episode ROCKED with Jean Paul Boodhoo,
who talked about TDD and other Agile concepts. Jean Paul is a
practitioner of TDD, as am I, and he explained the process and its
benefits very well. Congrats, Jean Paul on a job well done.
Rocky, on the other hand, gets it all wrong. I respect Rocky and
his contributions to the developer community, but he’s wrong on this
issue. Let me recap:
At the beginning of the dnr show, he comments on TDD. He makes
some invalid points. His points are bulleted, and my responses
are in green:
- It comes from the premise that you don’t have intellisense in the IDE.
- I’m really not sure how he came up with this since most other good IDEs have intellisense.
- In the Microsoft space, you lose so much by going down the road to TDD.
- This is a very vague statement, but I’ve
gained so much by doing TDD. My rate of development has sped up
because my debugging time has gone almost down to zero!
- Rocky misunderstands the process because he states that it involves writing a bunch of tests first before coding.
- TDD involves writing a single test first and writing code to fulfill it.
- He states that on large systems, you can’t do it one test method at a time.
- Can’t? Any large system is made up
of smaller parts, down to actual classes and methods as the building
blocks. TDD helps define the classes and methods. TDD
forces you to start small, but helps build a solid foundation.
- He says that developers don’t think the way of “test-first”.
- This is actually a true statement but in
no way is a weakness of TDD. Test-first is a learned method just
like programming as a whole. Learning to think first is very
similar to understanding the purpose of the code first. If you
can understand the purpose of the code before writing the code, you end
up with less code churn and a clean class design.
- Rocky relates that he has always made small test projects or console apps to be test harnesses to test code.
- I used to do that also, until I graduated to NUnit.
- These test harnesses are valuable, but as
you accumulate them, they are hard to manage, and since they are
valuable, you don’t want to throw them away. NUnit allows these
test harnesses to be managed effectively. Each test method is a
test harness.
Another false point made in conversation is that once these test
fixtures are created, developers will be hesitant to refactor code
because it would cause them to have to refactor all the tests that use
the code. Let me say from experience that unit test coverage
makes me want to refactore MORE! I am so comfortable refactoring
because I have unit test coverage that assures me that I haven’t broken
anything. In fact, when I am in parts of the code that is older
and doesn’t have good test coverage, I am scared of refactoring because
I have no way of being sure that I didn’t break anything. Note,
that I also use Resharper, and I would not want to code at all without
it or the DevExpress tools.
I love .Net Rocks, and I’ve listened to it from the very first show (and I’ve been a guest),
and I’m glad all viewpoints are represented, but the above bullet
points are incorrect, and I hope some of you will comment on them as well.
