TDD with Web Config

Question

All great stories they always start with those 4 magical words... I have inherited a system... no wait! that isn't right!

Anyway with my attempt at humour now passed I have not so much been given more I have to support an existing service.

There are many many issues when it comes to using this service, as an example one is to create a record of a person, you need to call 4 different parts of the services.

So, getting together with my Manager we decided that we need to stick another layer on top to add a facade to the common requests, to simplify the number things and the correct order to do them when creating a new site.

My question starts here if anyone wants to avoid the above waffle

So I want to use TDD on the work I am doing, but the service I have inherited (which will become our Data layer) has been strongly coupled with a database connection string located in a specific connetionstring node in the Web.Config.

Problem I have is, to decouple the service from the Config file will take weeks of my time which I do not have.

So I have had to add and App.Config file with the expected node into my Test project.

Is it ok to do this, or should I start investing some time to decouple the database config from the datalayer?

Answer 1

Try using Dependancy Injection to mock up your DataLayer.

In TDD you are not (necessarily) testing your datalayer and database but the BusinessLogic.

Some links:

• SO best practices of tdd using c# and rhinomocks
• TDD - Rhino Mocks - Part 1 - Introduction

Answer 2

You can use Dependency Injection to "untie" your code from web.config (or app.config for that matter):

http://weblogs.asp.net/psteele/archive/2009/11/23/use-dependency-injection-to-simplify-application-settings.aspx

Answer 3

I agree that you should probably look into using Dependency Injection as your working your way through the code to decouple your app from the config, however, I also understand that doing that is not going to be an easy task.

So, to answer your question directly, no, there is nothing wrong with adding a config file to support your tests. This is actually quite common for unit testing legacy systems (legacy being an un-tested system). I have also, when left with no other option, resorted to utilizing reflection to "inject" fake configuration values into the ConfigurationManager in order to test code that is reading configuration values, but this is probably a last resort.

Answer 4

As you mentioned Dependency Injection is the way to go. You also want to make sure that your consumers of your configuration object are not dependent on your specific configuration implementation such as the ConfigurationManager, ConfigurationSections, etc. To see a full example using custom configuration you can have a look at my blog post on Configuration Ignorance but basically it comprises of.

Your configuration implementation be it using a ConfigurationSection or an XmlReader should be based on an interface that way you can easily mock out your properties and easily change your implementation at a later date.

public BasicConfigurationSection : ConfigurationSection, IBasicConfiguration
{
    ...
}

To tackle how the the configuration is retried we use a configuration provider, the configuration provider for a particular configuration knows how to retrieve it's configuration

public interface IConfigurationProvider<TConfiguration>
{
    TConfiguration GetConfiguration();
}

public class BasicConfigurationProvider : IConfigurationProvider<IBasicConfiguration>
{
    public IBasicConfiguration GetConfiguration()
    {
        return (BasicConfigurationSection)ConfigurationManager.GetSection("Our/Xml/Structure/BasicConfiguration");
    }
}

If you are using Windsor you can then wire this up to Windsor's factory facility.

Hope that helps.