I am using MSTest to test an application. The test requires certain specific values, which are not normally present, to appear in the application config file.
So I need to substitute a well-known config file containing the values, at test run time, so that System.Configuration.ConfigurationManager points at the right file. (ie I am faking the real config file by substituting another one that I made earlier)
I can do all that, except that by the time my test executes, System.Configuration.ConfigurationManager has already read the config file, so that the new values are ignored.
Example code:
static TemporaryConfigFile config;
[ClassInitialize]
public static void ClassInitialise(TestContext testContext)
{
string sourceResource = "Intra_Matrix_Scheduler_Tests.Resources.test.config";
string tempConfigFileName = "test.config";
config = TemporaryConfigFile.CreateFromEmbeddedResource(Assembly.GetExecutingAssembly(), sourceResource, tempConfigFileName);
}
[ClassCleanup]
public static void ClassCleanUp()
{
config.Dispose();
}
(the above code creates a new config file with known test values, and points AppDomain.CurrentDomain("APP_CONFIG_FILE") at it. In the production code this technique of rerouting to another config file works perfectly if done at the start of the application)
The problem is that the following production line, when exercised by a test, does not retrieve the desired test values:
var dict = (System.Collections.Specialized.NameValueCollection)System.Configuration.ConfigurationManager.GetSection("ScheduledTasks");
and the reason is clearly that although the production code line and test code are by now pointing at the correct config file, the production config file has already been loaded into memory so the test config file is effectively ignored.
So the question is: how can System.Configuration.ConfigurationManager be forced to re-read the config file, or how else can the config file be faked? Alternatively how can I directly modify the in-memory config file for the duration of the test? (AFAIK I can't use dependency injection and MOQ to mock it, because System.Configuration.ConfigurationManager is static)
TIA