At the bottom of the triangle we have unit tests. These tests are testing code, individual methods in classes, really small pieces of functionality. We mock out dependencies in these tests so that we can test individual methods in isolation. These tests are written using testing frameworks like NUnit and use mocking frameworks like Rhino Mocks. Writing these kinds of tests will help us prove that our code is working and it will help us design our code. They will ensure that we only write enough code to make our tests pass. Unit tests are the foundation of a maintainable codebase.

But there will be situations where unit tests don’t do enough for us because we will need to test multiple parts of the system working together. This means that we need to write integration tests — tests that test the integration between different parts of the system. The most common type of integration test is a test that interacts with the database. These tests tend to be slower and are more brittle, but they serve a purpose by testing things that we can test with unit tests.

Everything we’ve discussed so far will test technical behavior, but doesn’t necessarily test functional business specifications. At some point we might want to write tests that read like our technical specs so that we can show that our code is doing what the business wants it to do. This is when we write acceptance tests. These tests are written using tools like Cucumber, Fitnesse, StoryTeller, and NBehave. These tests are usually written in plain text sentences that a business analyst could write, like this:
As a user
When I enter a valid username and password and click Submit
Then I should be logged in


At this point, we’re are no longer just testing technical aspects of our system, we are testing that our system meets the functional specifications provided by the business.

By now we should be able to prove that our individual pieces of code are working, that everything works together, and that it does what the business wants it to do — and all of it is automated. Now comes the manual testing. This is for all of the random stuff — checking to make sure that the page looks right, that fancy AJAX stuff works, that the app is fast enough. This is where you try to break the app, hack it, put weird values in, etc.

I find that the testing triangle on most projects tends to look more like this triangle. There are some automated integration tests, but these tests don’t use mocking frameworks to isolate dependencies, so they are slow and brittle, which makes them less valuable. An enormous amount of manpower is spent on manual testing.

Lots of projects are run this way, and many of them are successful. So what’s the big deal? Becuase what really matters is the total cost of ownership of an application over the entire lifetime of the application. Most applications need to be changed quite often, so there is much value in doing things that will allow the application be changed easily and quickly.

Many people get hung up on things like, “I don’t have time to write tests!” This is a short term view of things. Sometimes we have deadlines that cannot be moved, so I’m not denying this reality. But realize that you are making a short term decision that will have long term effects.

If you’ve ever worked on a project that had loads of manual testing, then you can at least imagine how nice it would be to have automated tests that would test a majority of your application by clicking a button. You could deploy to production quite often because regression testing would take drastically less time.

I’m still trying to figure out how to achieve this goal. I totally buy into Uncle Bob’s testing triangle, but it requires a big shift in the way we staff teams. For example, it would really help if QA people knew how to use automated testing tools (which may require basic coding skills). Or maybe we have developers writing more automated tests (beyond the unit tests that they usually write). Either way, the benefits of automated testing are tremendous and will save loads of time and money over the life of an application.

People have asked me for advice on how to learn TDD and I really haven’t had a good answer for them. I’ve tried doing lunch and learn sessions on TDD and other people have done half-day sessions on TDD. All of these are good, but there’s no way that you can cover all of the subjects that you would need to understand in order to do TDD on real world projects in such a short amount of time. Sure, there’s definitely value in these sessions, but when I did my lunch and learn session on TDD, I felt like people went away feeling more confused about all of the stuff that they just realized that they didn’t understand.

Which is why I’m developing the TDD Boot Camp, a comprehensive, three day training course that will cover everything that you need to know in order to do TDD on real world .NET projects. It will be very hands-on with a lot of coding exercises that will help you understand all of the hows and whys of test driven development in .NET. My goal is to teach all of the concepts, tools, and techniques that you need to know to do TDD so that, with some practice, you will effectively be able to do TDD (and hopefully teach others how to do it too!).

I’m working on scheduling some events, so keep an eye on the website as I get things set up. I can also come out to your site if that would work better. Hopefully this will fill in the TDD learning gap so that more people can start realizing the benefits of test driven development.

Test-driven development involves writing automated unit tests to prove that code is working. The test code is written before the implementation code is written. By writing the tests first, you will know when the code is working once the tests pass. Test names are written as sentences in plain English so that the tests describe what the code is supposed to do. Over time, you will end up with a large suite of automated tests which you can run in a short amount of time. These tests will prove to you that your code is working and will continue to work as you modify or refactor the code base.

Most software applications are intended to be used for many years, and throughout most of their existence, someone will be changing them. The total cost of ownership of an application goes far beyond the cost of the initial effort to create the initial version of the software. The first release is the easy part — you can build the application from the ground up, you don’t have many hindrances, and developers feel very productive. But as time goes on, productivity tends to decrease due to complexity, developer turnover, poor software design, and any number of other reasons. This is where software development really becomes expensive. So much focus is placed on the original cost of building an application without considering how the original development effort will affect the cost of maintaining that application over several years.

Test-driven development can reduce the total cost of ownership of an application. New developers on the team will be able to change the code without fear of breaking something important. The application will have fewer defects (and far fewer major defects), reducing the need for manual QA testing. Your code will be self-documenting because the tests will describe the intended behavior of the code. All of this leads to flexible, maintainable software that can be changed in less time with higher quality.

Software is intended to deliver business value, and test-driven development will help you write higher quality, more maintainable software that can be changed at the fast pace of the business. Test-driven development will lead to successful software projects and enable you to write software that will withstand the test of time.

For the past four years, I have worked at Quick Solutions and I have loved it. I came into Quick Solutions never having done ASP.NET and ended up getting all kinds of experience in all kinds of different technologies. I never could’ve learned as much as I did and I certainly would not be in this spot today if it weren’t for all of the really smart people that I got to work with.

So what am I going to be doing now? I’m still going to be leading a .NET project for Quick Solutions. There will be plenty of blogging and I have some side business ideas to work on. You will most likely see plenty of me at various community events, lunches, code and coffee, and whatever else is going on.

I don’t know what the future will hold, but I always remember the line in Good Will Hunting where Robin Williams says that he’s going to put his money on the table and see what cards he’ll get. I’m really looking forward to it.

Personally, I really appreciate this. I’ve done my share of speaking over the years (both technical and non-technical), so I don’t think that I’m a bumbling idiot, but I certainly am aware that I have a lot of room for improvement. My biggest fear when giving a talk is that people won’t understand or I’ll say something wrong and no one will ever let me know what I’m doing wrong.

So I don’t care if you have been speaking for 20 years or if you have never given a talk in your life, I appreciate your feedback and especially your suggestions. If you come up to me and say, “That talk was terrible,” I might not be so happy! But if you come to me and tell me what I can do to improve, I’ll all ears.

I’ll also be doing a short 30-minute session on how to convince others to do test-driven development. This is a touchy, difficult task that requires lots of tact, patience, and passion for TDD, but it can be done! I’m not sure what time I’ll be doing this, but check the schedule when you get there and you should find it (it will be in the vendor session timeslot).

Why do I say this? Because TDD has revolutionized the way I develop software and has helped me write flexible and maintainable software with fewer defects and is a less stressful way to get things done. I can’t imagine ever going back to writing code without tests, and as a result it’s really difficult to work with developers who don’t write tests because they will write code that is hard to test, which means I won’t be able to write tests either.

In today’s economy, it’s important to differentiate yourself from the crowd if you’re looking for a job, hoping to get a raise, trying to get a promotion, etc. TDD can be that thing that differentiates you from everyone else out there. At Quick Solutions, we are always looking for developers who practice TDD, but developers with any amount of TDD experience are very hard to find. So once you learn TDD (or if you already know it), please send me an email and I will try to find you a place on my team.

Not only are there great sessions, there are open spaces going on throughout the whole conference. Open spaces are self-organizing discussions where you propose a topic that you want to talk about and put it on the board in a time slot. So not only will you have the great eyes-forward conference sessions, there are several open spaces in each time slot where you can go and talk with other people on whatever topics you can think up. Last year I spent almost the entire conference in the open spaces and I had a great time.

Every year people come from all over the country to come to CodeMash, and last year it sold out. It’s well on its way to selling out again, so go bug your boss as soon as you can and tell him or her that you need to go to CodeMash.

Oh, and I’ll be speaking at the PreCompiler (the first day of the event) on OOP, the SOLID principles, and other “clean code” tips! It’ll be an interactive session when we’ll do some coding and learn from each other, so it should be fun. I know I’m looking forward to it.

Hope to see you at CodeMash!

Let me explain. Most people have some kind of layered setup in their projects. The basic architecture is 3 tiers — a UI layer, a business layer, and a data access layer.

Entity objects are going to flow through these layers. You will load, save, and delete entities. And in most cases, the way that you load, save, and delete these entities will be the same — but not always the same.

What we want to do is write code to handle the normal entities and write it just once. If we need to modify how things are done for a certain entity, then we’ll write code for that. By doing it this way, we should have little or no code duplication.

The diagram on the right shows our project structure. You will notice that we have some generic interfaces defined in the business layer and data access layer. That classes that implement these interfaces will perform the specified actions using an entity (the generic parameter T in each interface).

Here’s an example. The IRepository<T> interface contains methods that will talk to the database. I will create a concrete class called Repository<T> that implements the standard method of talking to the database. This is how most of our entities will be loaded, saved, and deleted.

public interface IRepository<T> where T : class
{
    T Get(long id);
    IList<T> GetAll();
    void Save(T target);
    void Delete(T target);
}
 
public class Repository<T> : IRepository<T> where T : class
{
    public T Get(long id)
    {
        // do stuff here
    }
 
    public IList<T> GetAll()
    {
        // do stuff here
    }
 
    public void Save(T target)
    {
        // do stuff here
    }
 
    public void Delete(T target)
    {
        // do stuff here
    }
}


Let’s say that I have a Customer entity that is persisted to a different database than the rest of the application. I now have a special case where I need to write custom repository code for a Customer. So I’ll make a class called CustomerRepository and have it implement IRepository<Customer>.

public class CustomerRepository : IRepository<Customer>
{
    public Customer Get(long id)
    {
        // do custom stuff here
    }
 
    public IList<Customer> GetAll()
    {
        // do custom stuff here
    }
 
    public void Save(Customer target)
    {
        // do custom stuff here
    }
 
    public void Delete(Customer target)
    {
        // do custom stuff here
    }
}


Here’s where StructureMap comes in. I’m going to configure StructureMap so that I can ask for IRepository<T> for some entity T and it will give me back the correct concrete class. This means:

IRepository<Product> maps to Repository<Product>
IRepository<Order> maps to Repository<Order>
IRepository<WhateverOtherEntity> maps to Repository<WhateverOtherEntity>
IRepository<Customer> maps to CustomerRepository (because CustomerRepository implements IRepository<Customer>)

Look at how easy this is going to be! I’m not going to have to do any extra configuration or wiring up to change how Customer entities are persisted. I’m not going to write any extra plumbing code, I’m just going to create the CustomerRepository class and implement an interface, and now my app deals with Customer objects differently.

Obviously there is some fancy plumbing going on behind the scenes, so let’s see how we set this up.

It’s really not that hard, actually, because most of the hard work is done by StructureMap. We just have to do some simple configuration.

Here’s how we initialize StructureMap:

public class StandardStructureMapConfiguration
{
    public void Configure()
    {
        ObjectFactory.Initialize(x =>
        {
            x.Scan(scan =>
            {
                // Automatically maps interface IXyz to class Xyz
                scan.WithDefaultConventions();
 
                scan.With(new RepositoryConventionScanner());
                scan.With(new GetObjectServiceConventionScanner());
                scan.With(new SaveObjectServiceConventionScanner());
                scan.With(new DeleteObjectServiceConventionScanner());
 
                scan.TheCallingAssembly();
            });
 
            x.ForRequestedType(typeof(IRepository<>))
                .TheDefaultIsConcreteType(typeof(Repository<>));
            x.ForRequestedType(typeof(IGetObjectService<>))
                .TheDefaultIsConcreteType(typeof(GetObjectService<>));
            x.ForRequestedType(typeof(ISaveObjectService<>))
                .TheDefaultIsConcreteType(typeof(SaveObjectService<>));
            x.ForRequestedType(typeof(IDeleteObjectService<>))
                .TheDefaultIsConcreteType(typeof(DeleteObjectService<>));
        });
    }
}


Let’s break this down and go over what I’m doing here.

scan.WithDefaultConventions();


This tells StructureMap to automatically map an interface IXyz to class Xyz. Most of the time, the names of your interfaces are just the concrete class with an “I” slapped on the front. This only applies to non-generic classes, so this isn’t necessarily helping us with our IRepository<T> example, but I do it on every project, so I thought I’d throw it in.

scan.With(new RepositoryConventionScanner());
scan.With(new GetObjectServiceConventionScanner());
scan.With(new SaveObjectServiceConventionScanner());
scan.With(new DeleteObjectServiceConventionScanner());


We don’t just want to use the default conventions, we want to add some of our own. Basically all we’re doing here is telling StructureMap that if I have a custom concrete class that implements one of these generic interfaces, we want to automatically wire those up. Here’s what one of the convention classes looks like:

public class RepositoryConventionScanner : ITypeScanner
{
    public void Process(Type type, PluginGraph graph)
    {
        Type interfaceType = type.FindInterfaceThatCloses(typeof (IRepository<>));
        if (interfaceType != null)
        {
            graph.AddType(interfaceType, type);
        }
    }
}


Moving on…

scan.TheCallingAssembly();


We want StructureMap to look inside the assembly that contains this code and apply the conventions to the types in this assembly. You can also do scan.AssemblyContainingType<T>.

x.ForRequestedType(typeof(IRepository<>))
    .TheDefaultIsConcreteType(typeof(Repository<>));
x.ForRequestedType(typeof(IGetObjectService<>))
    .TheDefaultIsConcreteType(typeof(GetObjectService<>));
x.ForRequestedType(typeof(ISaveObjectService<>))
    .TheDefaultIsConcreteType(typeof(SaveObjectService<>));
x.ForRequestedType(typeof(IDeleteObjectService<>))
    .TheDefaultIsConcreteType(typeof(DeleteObjectService<>));


Here we are wiring up the generic interfaces to the default concrete implementations of each interface. This is for the 95% of the time when we’re using the normal way of doing these things.

StructureMap needs to be initialized whenever your application starts (Program.cs for WinForms, App.xaml.cs for WPF, Global.asax Application_Start() for web apps). So in this case, I would new up an instance of the StandardStructureMapConfiguration class that I created here and call the Configure() method, which would do all of the ObjectFactory.Initialize() stuff.

I created a small sample project with this code. This is really easy to implement and it makes development a lot easier by reduces the amount of tedious plumbing code that you need to write.

The first thing is that you need to be developing a web application, not a web site. I can’t think of any reason to use a web site over a web application. So I’m going to assume that you already have a web application. I’m also using IIS 7. If you’re using IIS 6, you can still do all of the same things, but you have a different IIS console. But you should still be able to figure it out.

Step 1: Create a new application pool by right-clicking on “Application Pools” in the IIS management console. I suppose you could use an existing application pool, but I always like to make a new one. This way, you don’t have one application pool being used for multiple sites, because then you can’t change the application pool settings without affecting all of those sites. After you create the new application pool, click Start in the panel on the right to start the app pool.

Step 2: Right click on “Sites” in the IIS management console and select Add New Site. The physical path should be the local path on your drive to the folder that contains the web.config file for your site. In the “Host name” text box, just make up some host name. For example, “dev.mysite.com”. It doesn’t matter what you pick, just pick a host name that doesn’t actually exist. Also, click the “Select” button at the top and select your application pool.

Step 3: Edit your “hosts” file. This file can be found at C:\Windows\System32\drivers\etc\hosts. Enter this line at the bottom of the file:

127.0.0.1 dev.mysite.com

Use the host name that you entered when you created the new web site.

Step 4: Browse to the URL that you assigned to the site. In my case, http://dev.mysite.com. Your website should come up! Win!

Debugging your site using IIS is slightly different. In Visual Studio, edit the project properties for your web site and select the Web tab. Click on the “Use Local IIS Web Server” radio button and enter your custom URL as the Project Url (e.g. http://dev.mysite.com). Notice that there is also a checkbox that says, “Apply server settings to all users”. Ideally everyone on your team will set up IIS (because this way is much faster), but if that is not the case, you will want to uncheck that checkbox.

You can also debug your site by doing Tools / Attach to Process in Visual Studio (that’s Ctrl-Alt-P) and connecting to the w3wp.exe process (aspnet_wp.exe if you’re on Windows XP). If you don’t see w3wp.exe in the list, make sure that you check the “Show processes in all sessions” checkbox in the Attach to Process dialog box.

Happy debugging!