Question

I’m writing some xUnit tests for some helper classes that relies on some configuration settings, usually stored in App.config or Web.config of the executing project.

The config looks like this:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
    <add key="FileNamePattern" value="\\d{8}_\\w{4:20}\.png"/>
    <!-- and the likes -->
  </appSettings>
</configuration>

I’m running xUnit 1.9 with the GUI runner (xunit.gui.clr4.exe) and xUnit console runner (on the Jenkins CI server). Currently, I can “inject” these configuration values into the test environments by setting the xunit.gui.clr4.exe.config and xunit.console.exe.config files manually); however, this is tedious and error-prone.

I could also mock these configuration settings in a fixture. But using the same fixture across 10 different files is rather repetitive.

Is there a better way to mock these configuration settings with xUnit, such as providing a App.config file for the test project?

Answer 1

If your code assumes they are in the app.config, then xUnit.net supports having them wired up in there by providing one (typically when the tests are in a DLL file, this means you get a AssemblyName.dll.config file in the project outputs which the runner loads as the settings if it exists at load time).

Obviously no harm to use the DI principle to remove such dependencies in the first place, but I’d say don’t go messing with code before you actually get it under test first.

To keep it DRY, put the app.config in a central place and add it as a link (via the arrow on the Open button in the dialog). (Yes, there’s lots not to like about that – use only if you feel its the least evil approach.)

---

One thing to look out for is that changes don’t get reloaded in the GUI runner unless you ask for the assembly to be reloaded.