Cave Markings 

In agile development, it is common to hear people say "do the simplest thing that could possible work." This is a corollary to YAGNI or "you ain't gonna' need it." I don't hear many of my fellow developers outside of the agile movement arguing with those sentiments. It seems we can all agree that we should not exert effort beyond solving the specific problem at hand.

There is, however, contention about what the implementation of such pragmatic simplicity looks like. As a .NET practitioner of agile development, it is common for me to write tests before implementation code. I often write interfaces which have only one implementation. I may use an inversion of control container, an object-relational mapper and other infrastructure utilities which appear to add unnecessary complexity to developers with a different outlook.

One of the most glaring anti-patterns for simplicity in my view is the SQL data source. It seems very simple and pragmatic to some because it allows the developer to quickly create a forms over data application which will deliver value to the client. While I agree that there is tremendous immediate benefit in using the SQL data source for the initial delivery of value, there is also a tremendous cost down stream.

In my view, the SQL data source represents all that is flawed in RAD (rapid application development) tooling. It allows the developer to quickly get data into and out of a database into and from the user interface. It also tightly couples the data access implementation to the user interface making future changes very difficult to implement. Fundamentally, tools such as the SQL data source represent the software equivalent of a Rube Goldberg machine where each bit of functionality relies intimately on the implementation details of it's neighboring components.

The core problem in software from my experience is not the delivery of the initial version of any functionality. The core problem is that that I and the customer never know when or where the code will need to change, but we know for certain that it will change. Enabling change therefore becomes a top priority along with delivering value.

If I deliver value up front while discouraging later changes to the code, then I have not actually delivered value. I have in essence paid with a credit card. The cost of changing the code must be paid later with interest. This phenomena is commonly referred to as "technical debt."

In my agilist mindset, I view the avoidance of technical debt as an essential element of simplicity. High coupling and low cohesion are too high a price to pay for immediate gratification. Furthermore, I have found that once I become experienced with the tools and practices of agile development, there is little cost, if any, to building changeability into my implementation from the start.

Kind regards,

++Alan

I have given this talk several times recently, and I still have more dates scheduled. I created a Google Code repository to host my presentation downloads. You can find the relevant files here:

Introduction to Test-Driven Development With The ASP.NET MVC Framework

If you would like to catch this talk in person, I'll be doing my song and dance at these events:

• Memphis .NET User Group - April 24, 2008
• Indianapolis Code Camp - April 26, 2008
• Huntsville .NET User Group - June 16, 2008

Cheers,

++Alan

I just finished spending over 60 days without a steady gig. I did some contract work, but nothing long term.

I'm happy to report that I have a steady development contract with a Chicago based company.

I'll be working remotely with regular trips to the office. This opportunity plays to my strengths while still providing opportunity in new technologies.

The most significant change I've noticed after starting this contract is that I feel more outgoing. Looking for work wears me down, and I had started to withdraw without realizing it.

I actually gave four presentations during the first quarter of the year, but I never felt motivated to blog about them. I've been having a great time showing people the ASP.NET MVC framework, and the support for test-driven development that it provides.

If you're interested in hearing me talk about these topics, you can come by the NashDotNet meeting tonight. I will be giving an intro and a deep dive on TDD with the MVC framework at the Indianapolis Code Camp so mark your calendar.

Cheers,

++Alan

I've given talks on doing test-driven development (TDD), and I've had lots of conversations with other developers interested in giving it a try.  What I've found is that the simple setup and configuration hurdle is intimidating to most people at the start.  In this entry, I intend to remove that initial hurdle (and excuse).

The professional version of Visual Studio 2008 now includes MSTest unit testing framework.  I've been working with MSTest since the release of Visual Studio 2005 Team Developer Edition.  If you want to get started doing TDD in Visual Studio, I recommend you get the Professional version of VS2008 and learn MSTest.  I'm not recommending MSTest over any other unit testing framework.  I am asserting that the easiest way to get started is to use an integrated tool.

Unfortunately, purchasing the latest and greatest from Microsoft is too large a commitment for many people coming to TDD or Visual Studio for the first time.  I believe that TDD is essential, and I want to remove as many barriers as I can for people interested in implementing TDD in their development practice.  To that end, I have created project and item templates which enable a simple TDD workflow using the FREE NUnit testing framework and the FREE Visual Studio 2008 Express editions.

It should be noted at the start that I could use some VSX-fu to enable even more automation in the standard edition of VS2008, but the license expressly forbids the use of VSX APIs in the express editions of Visual Studio.  If you already have the standard edition of VS2008, or the standard or professional editions of VS2005, check out testdriven.net for seamless integration of NUnit, and several other unit testing frameworks, with Visual Studio.  For this discussion, however, we will stick with templates to avoid angering the "powers that be" in Redmond.  That being said, the templates and instructions for their use should work as advertised in any version of Visual Studio 2005 or 2008.

You will need to download and install the express edition of Visual C# (or Visual Basic) from here.  Next download this version of the NUnit framework and install it into the default location.  The references and paths in the project and item templates are specific to the 2.4.3 version of NUnit.  Finally, you will need to grab my templates and extract them.

There are four templates which are zip files, so don't extract them individually.  There is a project template and a new item template each for C# and Visual Basic.  I will be using the C# templates for this walkthrough, but everything here applies equally to VB.

You will need to manually copy the templates to the appropriate folders.  Typically user templates reside somewhere under Documents/My Documents.  You can verify the location by opening Visual C# Express Edition, selecting the tools menu, then the options pad.  In the resulting dialog, check show all settings in the bottom left corner.  You should now be able to select the Projects and Solutions node in the treeview.  This will display the current locations for item templates and project templates.

Once you know the proper template locations, copy NUnit Test Project - CS.zip to the project template location and NUnit Test Fixture - CS.zip to the item template location.  If you have touched all the bases to this point, you should see the new project template option when you select the file menu and click the New Project pad.

Select the NUnit Tests template under My Templates, give the project a name and click OK.  After the generation process is complete, press F5.  After a brief pause for compilation, the NUnit form should display and run the tests.  You can then enjoy watching the default tests happily fail.  Close the NUnit form to return to the IDE.

If you open the <projectname>.cs file, you will see a test fixture (class) with three default test methods included.  You can add as many tests as you want to this class, but you will probably want to group your tests into separate classes.  When you want to add another test fixture, simply right-click on the project and select add -> new item.  You will most likely have to scroll to the bottom of the item templates list to find the NUnit Test Fixture listed under my templates.

I like having my tests run on every compile, but you may want more options.  If you add a new NUnit test project to an existing solution, you will need to configure the solution for it to launch the NUnit GUI as the default start action.  Alternately, you can configure the solution to launch the currently selected project.  Right-click the solution in Solution Explorer and choose properties.  There you can select the Unit Test project if you want a single startup project.  You can choose the Current selection to have more control, or you can choose the multiple startup projects option, if you are feeling especially frisky.

If you have made it this far, then you have everything you need to practice TDD in Visual Studio.  From here, I recommend you get familiar with NUnit by reading their documentation.  Next, you should learn more about TDD and how to be effective with it.  I have compiled some extensive bookmarks for your convenience.

I hope this tutorial has helped eliminate your concerns and alibis over taking the TDD plunge.  I want to make it as simple as I can for interested developers to get started.  If you have any feedback or suggestions for this entry, please post it in the comments so that I can make this a "go to" reference for aspiring TDDers.

Cheers,

++Alan