NUnit and config - part 3: the strategy

So far on this blog I've posted two articles (is that what blog posts are, 'articles'?) (1 & 2) about handling config issues with NUnit. As I was writing them it became apparent to me that while I was using a particular set of tools (the MSBuild command line tasks in Visual Studio, CruiseControl and NAnt) there was a higher level strategy that they were a solution to. I think there's value in spelling out that strategy. I've made it very, very simplistic, so that even I can understand it when I read it back in 6 months time ...

First, the problem: Unit testing code that relies on values from configuration files is problematic, since NUnit operates outside the context of those config files.

The solution: NUnit has the facility to read its own config file in its own context (i.e. when the tests are running), therefore we should copy our config to that file.

The strategy:

• Copying files should not be done manually as this is almost guaranteed to screw up - it's also not logically possible for an automated build.
• The automatic process will have to rename the config file to match the NUnit project dll name.
• Any configuration sections that have been split out into separate files will have to be copied across as well and the relative paths to them maintained.
  
• Each project to be tested must have its own test project. For instance if you have a 'web' project, you should have a 'web.tests' project. Likewise if you have 'DataLayer' project you should have a 'DataLayer.tests' project. This means that you will not have to try to merge configuration from different projects into a single test project configuration.
  

I think that's the crux of it and I know it sounds simple, but I've seen plenty of projects where code isn't tested because of config issues, which frankly, is not a good enough reason.