Testing: I *want* to test web.config

Question

I want to do some unit testing on one of my projects. This is a web project, and there will only be one copy of this program running aside from development copies.

I want to write some unit tests that will use the web.config. I understand that ordinarily, a tester would stub out this external dependency because he wants to test the code without the test depending on the web.config holding certain values.

However, the web.config in my project is supposed to always hold certain values and I want to have a unit test that will fail if they are set to invalid values. For example, one of the values is a SQL connection string.

I want to write a test that will read the connection string from the web.config. I envision that the test could connect to a server with the connection string and perhaps perform a very simple command like SELECT system_user;. If the command executes successfully and returns something the test passes. Otherwise, it fails. I want the connection string to be read from the web.config in the project I'm testing.

Of course, the ConfigurationManager will not ordinarily look for a web.config in another project. I could manually copy the web.config from the original project to the test project, but I would have to do that before every test and there is no way I could count on anyone else to do that.

How do I make my test project read the web.config from another project?

Answer 1

You can load and explore other config files with the ConfigurationManager.OpenXXX() methods.

The WebConfigurationManager class specifically has a method for opening web.config files, and the documentation page I linked to has some more code examples. Once you have your configuration object loaded, you can explore it for sections and keys.

var cfm = new ConfigurationFileMap("path/to/web.config");
var config = WebConfigurationManager.OpenMappedWebConfiguration(fileMap);

Answer 2

It sounds like you are trying to validate settings in web.config, which is a deployment-level concern and is different from unit testing.

Unit testing tells you that your core logic is performing as expected; deployment verification tells you that the application was installed and configured properly and is safe to use. Unit tests are meaningful to developers, deployment verification is meaningful to the end user or administrator that is deploying the app.

In situation like this I like to build a "system console" into my apps. This console contains a number of self-diagnostic checks such as:

1. Ensuring the connection string(s) are configured properly
2. Ensuring that any 3rd party services are available and functioning
3. Ensuring that all configuration settings are valid and won't cause runtime errors (e.g. paths exist, the web user account has read/write access where needed, etc)

I strongly recommend you consider separating this sort of configuration and deployment verification from your unit test suite. Not only will it simplify your work (because you won't have to load a config file from another project) but it's also the sort of tool that customers really, really like :)

Answer 3

In your unit testing project, add an app.config file and add the settings from the web.config file that you would like to use for your tests.

Answer 4

I asked a similar question that you might want to check out:

http://stackoverflow.com/questions/1561663/how-do-i-test-that-all-my-expected-web-config-settings-have-been-defined

I ended up getting it working but the annoying part is my source control constantly locking the config file that is copied over. You can also rename the web.config to app.config so that it will compile into a non-web project.

Answer 5

It sounds like you're trying to squash a mosquito with a sledgehammer. Why not do this manually, as part of the deployment checklist; have a task to manually confirm the connectionString.

Or if you want to automate it, write a program to check the connectionString, attach it to your Continuous Integration server (assuming you have one) and fail the build if the connectionString is wrong.

Use Unit Tests for what they're intended for testing code, not configuration.