Reading the *. config file in unittest is depressing.

--After visual stuido 2005 integrates the unit test function, it is much easier to create and manage unit test than originally, and the unit test module and Code It will no longer "remain" in our DLL. However, the running method of VS 2005 unit test is the same as that of other unit test frameworks, and reflection is also used. In this way, some parameters in the Code dependent on the running environment cannot be obtained.

Just now I made a unit test for the method. This method depends on a custom parameter in Web. confing, so it is depressing. When I run the test code, I find that the configuration parameter in the config is always null. This problem should not be complicated at all, but when I checkProgramThe following warning is found in the output information during compilation:

'System. configuration. configurationsettings. receivetable' is obsolete: 'This method is obsolete, it has been replaced by system. Configuration! System. configuration. configurationmanager. deleetask'

I was confused by this warning. I thought it was the old method. What problems were abandoned? The original simple problems became more and more complex :(. So I changed the configurationsettings to configurationmanager according to the compilation prompt. Obviously, this is futile. the problem persists, but I still cannot get the parameter values in the config file.

After a long wait between configurationsettings and configurationmanager, there is still no improvement. After being depressed for a long time, I suddenly thought that the config file is a global configuration of an application and should be loaded and effective only after the application is started normally. Since unit test loads assembly and Class Using Reflection, and then invoke the method to be testedIf the application is not started normally, the config information will certainly not be available.. So immediately start the application itself, and the parameters configured in the config file are indeed obtained.

Therefore, during unit test, you need to check whether the tested method depends on the parameters in the config file. If you need to temporarily use the hardcode constant, perform our unit test. Otherwise, we will only be depressed.

The above problem occurs in the ASP. Net project to read the Web. config file. As for the *. config file of the winform program, this problem should also occur, but it has not been verified in person.