Modifying application settings in unit tests

Question

I have a class library I want to unit test using Microsofts unit test framework. Some of the classes I want to test are configured using application settings. These settings are defined inside the Settings.settings file having application scope and suitable default values. When the library is used by the application these settings can be overriden in the App.Config file. If not the default values are used. That's exactly how I want it to be.

In some of my test cases I want to test special combinations of setting values but I don't know how to change the values seen by the class under test from the unit test code. These settings will always have their default value loaded from the attributes of the code generated class.

In my library class I access the settings like this:

var mySetting1 = Settings.Default.MySetting1;
var mySetting2 = Settings.Default.MySetting2;

How do I modify these settings in an unit test before the setting is accessed by the class under test? Making the internal settings class accessible by the unit test does not solve the problem as the settings have application scope and are read-only properties on the settings class.

Brenan

Answer 1

After spelunking into the ApplicationSettingsBase and associated classes I've come up with this solution to my problem. Not particular beautiful, but it certainly gets the job done.

The code generated settings class is internal to the class library project and it has to be accessible to the unit test project. Add the [assembly: InternalsVisibleTo("UnitTestAssemblyName")] attribute to AssemblyInfo.cs in the class library project.

The settings are lazy loaded from the attributes on the settings class when a value is accessed. First step is to do a "dummy" read of a setting to force this lazy load. When unit testing you want to avoid settings values changed in one test to affect another hence it is necessary to "reset" the settings before lazy loading them. That can be done using the Reload() method. This code is placed in the test initialize method:

Settings.Default.Reload();
var dummy = Settings.Default.MySetting1;

The underlying values now exist and can be set in each test method. Remember to use the correct type as the code generated getters will do a cast:

Settings.Default.PropertyValues["MyStringSetting1"].PropertyValue = "Foobar";
Settings.Default.PropertyValues["MyDoubleSetting2"].PropertyValue = 3.1416D;

Brenan

Thanks for this, would never have figured it out on my own. – Rosabella

Thanks, this solution still works in 2024 and I'm starting to understand why MS redesigned this pattern to IConfiguration. – Sheronsherourd

Answer 2

I'd create a wrapper class around the Settings class then pass that wrapper around. Then you can mock away your settings class with ease.

The only other thing I can come up with is the slightly more light-weight and easier to mock option of making your settings file implement an interface which reflects all your settings. It's not really much different for the caller, but you'll have less plumbing to do when adding new settings.

Neither is fantastic, and it is a pain to have to do it for auto-generated code, but it seems that's what we're stuck with as far as I can tell if you really want to remove the dependency on the settings file.

E.g. for a settings file containing a string Application setting and an int User setting:

internal sealed partial class Settings : IMySettings {

    /*
     * here be auto-generate code (and dragons!)
     */
}

internal interface IMySettings
{
    string ApplicationSetting
    {
        get;
    }

    string UserSetting
    {
        get;
        set;
    }
}

Haskell

I would rather avoid injecting settings since I have many libraries and the number of dependencies to inject grows a lot as I move up the dependency hierarchy. Also, wrapping classes that are code generated by Visual Studio is tedious. I was hoping for a solution that wasn't pure DI, but would work well with application settings in .NET. – Brenan

Unfortunately I don't think there is one, the best you may be able to do is set user setting, but application settings just won't change outside the file. The only other thing I can come up with at the moment is using an interface, slightly more lightweight but still, as you say, pure DI. – Haskell

Answer 3

So your setup may be different, but what worked for me was using Moq to mock the Microsoft.Extensions.Configuration.IConfiguration like this:

public void UnitTestName() {
//arrange
configMock = new Mock<IConfiguration>();
configMock.Setup(x => x.["keyName"]).Returns("value");
//assert
...
}

Sigmund

Thanks for the answer. However, this question was asked more than 10 years ago long before IConfiguration existed. It's about the .NET Framework configuration system based around App.Config and its integration with Visual Studio generated settings. – Brenan