I recently did a small presentation for my officemates as a refresher for Test Driven Development:
This presentation is based heavily on Ben Hall's Red, Green, Refactor! presentation, - in fact you could get the code for this presentation from there as well. 
A few weeks back while listening to .NET Rocks Episode 408, I cringed so badly when I started hearing Dr. James Whittaker, who is, apparently, in charge of Visual Studio Team System's testing tools (which I surmise includes the oft-admonished MS Unit Testing framework), talk about test driven development and his gripes about it.
Right then and there I saw it: Microsoft's attitude about test driven development has been totally wrong, precisely because they were asking the worst possible person about it. Whittaker is the worst person to talk about test driven development, because he's focused on testing.
Microsoft failed to understand, outright, that test driven development is NOT about testing.
Scott Bellware responded to Whittaker's statements via the Hanselminutes podcast, wherein he offered The Last Word On Test Driven Development on Episode 164. There, he questions (at around 5:30 into the podcast) "why test-driven development is coming out of a conversation about software quality and software quality tools":
I think it's quite sad though that no matter [how much we tell people] that TDD is about design rather than testing, that it never really sank in...
Questions about software quality are damaged when we let them fall over into conversations about test driven development...
The goal with [TDD] isn't really a unit testing goal although we're borrowing unit testing tools to achieve the goal... [We're almost like] "demonically" possessing unit testing to achieve other needs.
["The Last Word on TDD" on Hanselminutes]
I said as much when someone asked on Stack Overflow whether TDD takes focus away from design. In my response, I stated that it's precisely the opposite -- that, once again, TDD is all about software design:
If done right, Test Driven Development IS your design tool.
[...]
Test Driven Development, done right, should make developers highly aware of design pitfalls like tight coupling, violations of DRY (don't repeat yourself), violations of SRP (Single Responsibility Principle), etc.
If you write passing code for your tests for the sake of passing your tests, you have already failed: you should treat hard to write tests as signposts that make you ask: why is this done this way? Why can't I test this code without depending on some other code? Why can't I reuse this code? Why is this code breaking when used by itself? ["Does TDD take away focus from design?" on Stack Overflow]
The reason why I don't take this misconception lightly is because this realization came to me the hard way -- I was part of a project wherein Test Driven Development was grossly misunderstood by previous members of the project:
There was... a failure to recognize that TDD is not about tests, it's about design. The rampant case of singleton abuse in the unit tests made this obvious: instead of the test writers thinking "WTF are these singleton = value; statements doing in my tests?", the test writers just propagated the singleton into the tests. 330 times.
The unfortunate consequence is that the build server-enforced testing was made to pass, whatever it took["When TDD goes red" on Dotnet @ Kape ni LaTtEX]
The attitude Microsoft took regarding this issue explains a lot why testing is an add-on "luxury" feature to Visual Studio, which you pay extra for, and not part of its core features out-of-the-box, and on top of that made it definitely illegal to implement in Visual Studio Express. Hiring a testing expert to implement a software design engineering guide lead to the inevitable misrepresentation of the value of TDD.
Unfortunately, treating TDD as a luxury feature gives the impression to hobby and professional software developers alike that test driven design is nothing but a bell and a whistle in Visual Studio -- which it is not. Test driven development is a paradigm in software development, and to many it has become a fundamental way of ensuring that code for software of any size and complexity is flexible and maintainable and remains that way.
So repeat after me: TDD is about design. It's NOT about unit tests. Tell that to the every developer who asks what TDD is all about, and to every developer who thinks TDD is about testing.
In behalf of the Philippine .NET Users Group, I'd like to invite everyone to attend this event. It will be held on Saturday, June 7, 2008, at the Microsoft Philippines Offices at 6750 Ayala Ave., Makati City.
Sign up now for this event at http://www.clicktoattend.com/?id=128964
I'll be conducting a talk on Silverlight Unit Testing on that event.
A shoutout and big thanks to cruizer who conducted a similar Silverlight Unit Testing talk over at Singapore's Heroes Community Launch, and is likewise helping me with my talk, although there would be big differences between his and my presentation.
Abangan. 
Last week, I had a short but enlightening conversation with Scott Hanselman over Twitter.
I had asked him what 20% code coverage, signified by 700+ tests, meant. This metric was related to a project I was in: it was a fairly large codebase wherein a lot of TDD was foregone on its later versions. I was concerned that, 20% coverage meant that the unit tests were either becoming irrelevant, obsolete, or futile. Many times I've thought about recommending that the unit tests to be abandoned altogether.
Scott then asked me back a question that rather startled me: is the 20% that our tests cover the “right” 20%? By “right”, he meant that, are these the unit tests that were testing the functionality that the users of the application were using the most? Are these tests verifying the part of the application that gets used each and every day? It was a simple idea, but very enlightening nonetheless.
Around that same time Steve Yegge published a rather controversial post, accusing data-modelers – whether in the physical database side or in the logical, class definition side of the equation – of using data modeling as an excuse to delay work, much like a n00b will use comments to explain the code to himself. That over-normalization and class representation in statically-typed languages were diversionary tactics so as not to go straight to writing code that actually contains functionality.
Several teammates have had a nerve-wracking week thus far.
We're in-between versions of our software, and while the requirements for the new version are still on the drawing board we're looking back at our last release (on a new subversion instance), sifting through areas we just patched up during the run-up to our project release and replacing the code with something more robust and maintainable. You know, actually taking off the plywood you used to board up "holes in the wall" to actually replace the wall itself. Things like unused fields, redundant calls, long methods with SRP violations, incorrect object representations.
One of our teammates is redoing the object representation of our most important core object, including its underlying DB representation; a second is converting our DAL to be compatible with NHibernate's generic implementation of Find() to be able to get rid of ILists and finally convert them to IList<T>; yet another is sifting through most of the objects fixing an error in a notifier class to correct the behavior of MarkDirty(). It's a lot of work, but thankfully the unit tests are there, however few and nearly futile they might be considering the size of "the beast." (more...)
Back when I was working for a big bank, I was tasked to develop and maintain some COBOL applications, which were mainly text-reports of some sort. Coming from an era where source control was still science fiction, versioning was done using the following convention:
Of course you can only imagine how the final program looked like. It came to a point where actual working code was only 10% of the source.
Fast foward to today, where we're working with C# 2.0, Subversion and CruiseControl, but I would still see big blocks of commented code from the code updates. When I ask the people who committed the code, it's either they forgot about it, don't know what to do with it, or want to keep it for future use. Sometimes these same people get mad at me if they find out that I deleted their commented code.
The past four days has been particularly grueling: I grossly underestimated the singleton abuse I talked about. In the end I ended up revising more than 500 compile errors (the 236 errors stated in the previous post was just the start of it!). There are 330 compile errors left, but I gave up on them.
Why?
Two reasons: the errors were already those in the unit tests, and because these tests have, themselves, abused the singleton that I was fighting against.
Facing this, I started to think the use of Test-Driven Development has, to some extent, failed in this project. I hope I don't offend some previous project members (I absolutely mean none), but, here are my insights as to why TDD failed here:
Though I've been, purportedly, a believer of Test-Driven Development, I've been admittedly amiss in putting it into practice, even in my most recent project.
A wake-up call by a colleague lamenting that we're moving backwards, succumbing to the dark abyss of deadline-driven development, and perhaps, deadline-oriented programming. However, it also underscores the fact that it is very easy to lose focus, especially when you don't have a Jeremy Miller in your team.
It's been almost three years since I found out about TDD, Agile, XP, and other "progressive" SDLC processes, but I have yet to get an opportunity to apply it even on my own. It hurt to find out that my early unit testing experience with VS2005 was the wrong way to do it.
Anyway, I'm not really hurrying. The whole concept is not a process or a plan that can be adopted just like that; it is a paradigm shift that will take time for me (or much worse, a company) to appreciate and digest. So for now I'll just put down some "best practices" notes on ways to move toward the Agile direction in any .NET project that I'll be undertaking in the future:
I've recently gotten my hands on VS2005 Team Suite (just a trial edition).
I have long wanted to try out the integrated unit testing tools. However, I must admit I have never been able to extensively try out unit-testing or test-driven development (TDD) inspite of the fact that NUnit and TestDriven.NET are freely available.
Although Microsoft apparently implemented their own unit testing framework, the code for these unit tests are quite similar to that of the NUnit testing framework, with the same Assert syntax most TDD practicioners are familiar with.
I am not sure at the moment but I believe Microsoft even added some additional overloads for the existing set of Assert methods from NUnit.
