Test-driven development with ASP.NET MVC - where to begin?

Question

I've read a lot about Test-Driven Development (TDD) and I find the principles very compelling, based on personal experience.

At the moment I'm developing a website for a start-up project I'm involved in, and I'd like to try my hand at putting TDD into practice.

So ... I create a blank solution in Visual Studio 2010, add an ASP.NET MVC Website project and a test project.

I also add a class library called 'Domain', for my domain objects, and a test project for that.

Now I'm wondering where to begin. Should I be writing a test before I do anything right? The question is - should I start writing tests for domain objects? If so, what exactly should I be testing for, since the domain objects don't yet exist?

Or should I be starting with the Website project and writing tests for that? If so, what should I write a test for? The Home controller / Index action?

Answer 1

I typically start by collecting a set of stories for the application I'm going to develop. From that I generate a domain model, usually on "paper". I organize the stories that I'm going to implement and start creating the domain model in the DB for the first set of stories.

Once I have the initial DB, then I use an ORM, in my case, LINQ to SQL, to map the DB tables onto a set of initial classes. I don't typically unit test generated code so this gives me a fair amount of code as a base to start with. I then create a stub method, which throws a not implemented exception, to implement one feature of the first domain class I'm working with. Typically, I start with validation logic. Once you have your stub method, then you can use the VS right click menus to create one or more unit tests for that method. Then you're on your way.

Once I've finished with the domain objects for the first story, I then start working with the MVC aspects. First, I'll create the view models for the first view. These are typically just an empty container class as this point. Then I'll create the view and strongly type it to the view model. I'll start fleshing out the view, adding properties to the view model as needed by the view. Note that since the view model is simply a container there aren't typically unit tests associated with it. It will however be used in subsequent controller tests.

Once the view is complete (or at least my initial concept is complete), I then create the stub controller action or actions for it, again the stub method simply throws a not implemented exception. This is enough to get it to compile and let me use the tools to create unit tests for it. I proceed as needed to test the method(s) and ensure that it acts appropriately to the given inputs and produces an appropriate view model. If the method can produce multiple view models, i.e., render multiple views I may iterate over the process of creating view models/views/controller code until the story or stories are complete.

Repeat as necessary until your set of stories are implemented, refactoring along the way.