Development Driven Tests

I’ve got the title wrong backwards to make a point.  That point is coming…

I attended .Net boot-camp a few weeks ago and practiced Test Driven Development.  We talked about new features to add to CodeCampServer (the open source project used as the coding sandbox for class).  Our instructor drew sequence diagrams on the whiteboard and we designed the interfaces and interactions the features would require.  We assigned tasks, wrote tests that failed, then wrote code to make them pass.  It was great.  To me it felt the way development should feel, like we were doing it right.

Now I’m trying to work through how to take these methods, which feel so right, back to work.  It seems to me this is a common problem developers like me deal with, and I want to succeed.  So I’ve been working through a project that uses the agile tools and methods demonstrated at boot-camp and tries to flesh them out using code that will run in our environment at work.  My thought was that a finished project, built using the methods I want to use more at work, would go a long way to convincing my coworkers of the value these methods and tools could bring.  Here are the ingredients I’m throwing together in my example project:

• Onion Architecture (to remove some pain caused by tightly coupled areas of our applications)
• Test First Development (using NUnit and Rhino Mocks, to realize the increased code quality and code longevity that TDD proponents promise)
• Object-Relational-Mapping (using NHibernate, because I’m tired of maintaining dozens (hundreds?) of stored procedures per app)
• Visual Studio 2005 (because that’s what we use at work)
• Web Forms using the Supervising Controller pattern (because we can’t use MVC at work and this seemed to me a testable next best thing for web forms)

I’ve named my project “NCharlie” for now, since it uses at least 3 technologies that start with “N”, and since it will help Charlie (me) chronicle my journey towards becoming a better programmer.  It is a simple task management tool (add to-do items, assign tags to them, search for them).

This brings me back to the title of this post, and my point.  After spending a few hours on NCharlie I’m realizing that it is hard to make the transition to TDD.  I have been making the software work first for so many years now that it feels unnatural to write tests before implementations.  I am now at the point where I am writing more tests… but NCharlie is already working!!  I fell hard back into my old pattern and implemented the design before I wrote tests.  Sure I wrote a few tests up front, but I have to be honest with myself and admit they were only copies of tests I learned about at boot-camp.  Anything specific to the design of my test project has been just plain hard for me to test first.

So is NCharlie just going to end up on my FAIL list?  I hope not… I still have plans for it (actually it is the reason I’m starting this blog.)  The way it sits now NCharlie is of no use to me or my coworkers because it doesn’t prove what I set out to prove… in fact it disproves it! 

This is a wake up call for me, because I think a developer who excels at writing tests first must also have a good handle on other principles/patterns that distinguish an average developer from a master.  So I’m average, that’s ok.  But I don’t want to stay here.  I have been reading books and blogs for a couple years now that describe pragmatic and agile methods I know I want to use in my career as a developer.  I’ve been successful with some, but the more I learn the more I realize how far I have to go.

So here I go… new plan.  I’m going to dissect NCharlie and show you its ugly guts in public.  I have no shame.  In fact I’m quite proud of some of it… even though it is blatantly not original.  It uses code from open source projects like CodeCampServer and Tarantino.  I can however, take credit for getting them all working together from “File, New Project”.

So let’s call this an introduction to a series of posts.  Mainly I want to document the process for my team at work and for myself so we can use this as we hopefully start to integrate these methods into our workflow (if I can get NCharlie to the point of proving its usefulness).  In the next post I’ll attempt to strip down NCharlie and start over at the point where TDD actually shows some benefit.

Next in series -  NCharlie: Test Driven Development – part 1 >>