D'Arcy from Winnipeg
Solution Architecture, Business & Entrepreneurship, Microsoft, and Adoption

Iteration 1 – Tales from a TDD Project

Wednesday, July 1, 2009 11:33 AM

I just completed my first iteration on a project I was injected into at work. What makes this project interesting is the approach to software development as well as the technology makeup. Many developers wonder what its like to switch from traditional methods and adopt something like TDD or OSS tools like nHibernate, Rhino Mocks, Castle Project, etc. I wanted to share some thoughts and what my experiences have been after completing my first iteration in exactly that type of environment.

TDD – Different, yes…Valuable, absolutely.

My first experience to TDD has been a career altering experience. After this project, I can say absolutely that not doing test driven development would be difficult. With that said, I wasn’t doing TDD this first iteration…more like TAD: Test AFTER Development.

I always looked at what I was going to write from a pure implementation point of view…here’s what its supposed to do, so let’s get going building it. But with a test-first approach the tables are turned: here’s what its supposed to do, so let’s build the scaffolding that will validate what it is we’re going to write. This is a big paradigm shift for many developers, and even on our team I feel that there’s some sentiment of resistance…or maybe just wrestling with understanding the value of writing many lines of test code compared to the actual production code. For any team trying something new, I think this is normal.

Development Tools = Learning Curve

I think I would encourage people wanting to do TDD to actually take a test-after approach for the first iteration, or for any spikes available before the actual project begins. One key reason is to get accustomed to the tools available and how they work.

We’re using nUnit for our testing which is a unit testing framework with plug-ins to VS.NET. I’ve been exposed to nUnit before, but this is the first project where it played such a major role. It didn’t take much to learn the basic features, but it was through the process of the iteration that I discovered other aspects like the Syntax Helpers to make your assert statements more readable.

Going hand-in-hand with nUnit is Rhino Mocks. Oren’s popular mocking framework allows you to create mock objects for your tests that you have control over. So instead of having to new up an Employee object and ensure that it has certain values set, which may require actually executing code, you use a mock object instead that you have control over dictating how it acts and responds. It took me a while to get my head around some of the concepts and how it uses what it does, but once there you realize how easy it can be to robustly test your code.

Re-Sharper is a productivity product for VS.NET that isn’t directly required to do TDD, but should be a requirement for any C# development project. Re-Sharper provides improved code maintenance functionality that you would otherwise be relying on a developers skill with copy and paste to perform. It also provides extensive search capabilities which makes finding things in your project very easy. The downside of re-sharper: OMG, so…many…shortcuts! I’m constantly amazed at how devs I work with will just fire off “Oh, just do ctrl-alt-F6 to do that” when asked how to do something in re-sharper, or to offer how to make a task easier with re-sharper. Once you use it enough, I’m sure the shortcuts get ingrained in your head…but for newbies to the product, it can seem daunting.

While I mention that there’s a learning curve, that shouldn’t be seen as a negative thing. Velocity is an important concept when dealing with changing your development practices: there will be pain up front, but as devs get more experienced and comfortable their productivity will increase. Also, there are Microsoft tools in this same space. Team System has a Test version of VS.NET, and also (I assume) has unit testing features baked into the Dev version of VS.NET. There are also other mocking frameworks than just Rhino Mocks, and I’d be surprised if some of the Re-Sharper features didn’t make it into VS.NET 2010. Still, these tools are solid, accepted, and have a developer community supporting them. Solid choices.

The Importance of Trust

I did a blog post around trust a while back, and those concepts are definitely proven true on this project. Our team has dev leads and technical architects, but the focus isn’t on who does what. The focus is on the project success and on helping make each other better. It’s an infectious environment that encourages discussion, debate, and disagreement (without being disagreeable mind you) while still holding to our values of keeping our commitments and delivering quality. The environment of trust, especially when a project tries to tackle so much new methodology and so much new technology, is critical to the projects success. You don’t want defensive people on your project, you don’t want those that are unable to compromise or consider other people’s views, and you don’t want those that are known to not work well on a team. Teamwork is key in a project like this, and I’m very fortunate to be surrounded with the people we have.

This is getting long, so I’m going to stop it here. I didn’t mention nHibernate or Castle Windsor in this post because those are more architectural aspects…while they do have technical implications, they aren’t the same as the tools I mentioned above. I’ll do another post on that topic. For now, hope this helped and let me know your thoughts and feedback.



# re: Iteration 1 – Tales from a TDD Project

And next, MassTransit??? ;p

Seriously, awesome post! It's great to see when others talk about TDD experiences.

7/1/2009 7:34 PM | Robz

Post a comment