I’ve been using TDD for server-side development. I’m not really sure if the benefits of having all of my production code surrounded by unit tests outweigh the disadvantage of spending 4x more time than needed on refactoring.
But when I’m developing UI code, I simply cannot apply TDD. To all fundamentalists out there, the first law of TDD states that “you may not write production code until you have written a failing unit test”. But how can this be if you are developing UIs?
(One can use acceptance test frameworks like Selenium, but that doesn’t count, because you don’t interact directly with the source code.)
So, can I tell my manager that because of the new >90% code coverage policy I cannot write user interface code?
First off, even Robert Martin has testing challenges with UIs.
When TDDing a UI, you write “behavioral contracts” that get as close to the action as possible. Ideally that means unit tests. But some UI frameworks make that inordinately difficult, requiring that you step back and use integration or “acceptance” tests to capture how you expect the UI to behave.
Does it not count if you can’t use unit tests? That depends on which rules you’re using to keep score. The “only unit tests count” rule is a good one for beginners to try to live with, in the same vein as “don’t split infinitives” or “avoid the passive voice”. Eventually, you learn where the boundaries of that rule are. In one podcast, Kent Beck talks about using combinations of unit and integration tests, as appropriate (adding, if I recall correctly, that it doesn’t bother him).
And if TDD is your goal, you can most certainly write Selenium tests first, though that can be a slow way to proceed. I’ve worked on several projects that have used Selenium RC to great effect (and great pain, because the tests run so slowly).
Whatever your framework, you can Google around for TDD tips from people who’ve fought the same battles.