Test Driven Development is great. No, scratch that. TDD is life saving. But it's still young. Yes, event though it was being implemented more than a decade ago, it's still in its infancy stages. There's lots of FUD(fear, uncertainty, doubt) going on around it, but those that “get” it truly become what is now commonly known as “test infected”.
Some more problems related to infancy emerge as I make my way through a project which has a “mixed mode” development approach. It was done with a big upfront architecture design, and also with high level layers and SRS documents for some components. But the implementation is being done in a totally TDD way.
But a lot of questions rise up on account of this approach:
- How do you reconcile TDD with a structured approach to project management? Since TDD supports and endorses “design as you go“ development, it's hard to do up front design of anything because it just feels “wrong“. The way we are doing it is that we have several big up front designs of the system's parts and components, but we implements them as test cases based on requirements. Those tests are written one by one in a TDD manner and each of them goes through the Red, Green Refactor cycle.
- How do you convince your team about doing it? lots of FUD emerges once you introduce the idea of “testing first“. There's no other way that I've found but to take 2-3 days and actually do small hands on exercises with the team, preferably in pairs, using TDD. After that they are hooked.
- How do you introduce the concept of Pair Programming into a FUD environment? You don't. You simply *do* it. “Sit with him and do this together, OK“ usually works. “Try to switch with each other every such and such time so that you both learn and do at the same time, OK“ works as well after that..The phrase “pair programming“ should not even be uttered until the project is done with, or you will get FUD. Oh yes. learned this the hard way.
Nothing is set in stone. It's all still a “learn as you go” experience for us and a lot of other projects. To be honest there's no way to introduce XP fully with all of its tenets into a structured organization easily (unless the CEO decides about it personally). It's just too big a shock. TDD is a start.
I'm quite curious as to how Microsoft is embracing this change in concept. They've hired one of the authors of NUnit and we're starting to see some articles here and there about test driven development, but I wonder. Are they actually trying to do XP or even TDD somewhere in their product teams? Are there actually developers at Microsoft using NUnit or some other tool going “Red, Green, Refactor” on their code? how would an XP process work on products as large and vast as the ones Microsoft is usually working on? will we see new documents from the PAG group about implementing the tenets of XP on an enterprise class application? I wish this is in our future. XP and TDD are missing a guiding hand. Microsoft is a great leader to set the pace on this issue.
In next year's tech-Ed I'd like to see some sessions on these issue. some real world sessions on XP and TDD. How to use Nunit. I bet there would still be plenty of people who will not know all this stuff. How about putting TDD support in Whidbey (like most of the Java IDEs have had for a long time now)?