Lots of people write to ask about the use of configuration files with NUnit. Usually, they have put some setting in a config file – somewhere – and are wondering why NUnit doesn’t seem able to find it. In this post, I’ll try to summarize the main issues around NUnit’s use of configuration files. It really isn’t all that complicated, once you understand a few things…
1. NUnit does not read config files!
It’s actually the .NET framework itself that reads a properly named config file when an application is loaded. By default, it looks for a config file named
Usually, you won’t need to change either of these config files, but it could be necessary if you are trying to run NUnit under a different version of the .NET framework. In particular, you won’t put any test settings in these configs, because…
2. Your tests cannot “see” nunit-gui or nunit-console config files.
When NUnit runs your tests, it creates a separate AppDomain in order to give them a different set of directories for finding assemblies and a different configuration file from NUnit itself. NUnit tells the .NET framework the name of the configuration file to use. The name of the file varies depending on how you load your tests…
- If you load a test assembly directly, such as mytests.dll, the config file must be named mytests.dll.config.
- If you load an NUnit project, such as mytests.nunit, the config file must be named mytests.config.
- If you use NUnit’s Visual Studio support to load a Visual Studio project or solution, such as mytests.csproj or mytests.sln, the config file must be named mytests.config.
In all of these cases, the config file must be in the same directory as the assembly or project that you are loading.
You might wonder why NUnit works this way. Placing the test settings in a file separate from the NUnit config files is necessary so config for each project and to minimizes the chance of errors in the NUnit config. We use two separate naming conventions for assemblies and projects to allow different settings for these different kinds of test runs. However, the naming issue has ended up causing a lot of confusion and will probably be phased out in a future release.
If you aren’t sure whether your config file is being used, a good trick is to put a special setting in it and write a test to see if that setting can be retrieved. For example,
public void CheckConfigFile()
Assert.AreEqual( "1234565", ConfigurationSettings.AppSettings["configCheck"] );