views:

183

answers:

3

I am using the built in test framework in VS2008 and I would like be able to write a test that makes sure all the expected web.config settings have been defined so that if by accident one is removed or changed my suite of tests will detect it and not have to be tested in a runtime scenario. How would I set this up?

I do not want to setup a mockup of my web.config since I don't want to maintain two versions and this would make my test invalid anyways since I am really trying to capture the fact that the project's web.config is correct.

Any suggestions, alternatives, hints?

Solution: I ended up using the copy in the pre-build that was suggested with one change. On copy I rename the web.config to app.config so that the test project would automatically pick it up.

I tried to split out the config files as suggested as well but the problem I ran into was when the test project ran, it actually didn't run out of the bin directory (which setting the config files to 'Content' type would copy to) but instead to a results directory that has been pre defined. I could not figure out how to make it copy thos extra files to this results directory so the config files could never be found.

+2  A: 

I'am using the pre-build event to copy working web.config to your test project directory.

Set the command line of the pre-build event of test project to string like this:

copy $(SolutionDir)\YourWebAppDir\web.config $(ProjectDir) /y

After that your tests will always run with actual web.config version.

Comment to pcampbell's answer:

I think if you use the configSource attribute you can just set it to the same path in web.config of your web app and app.config of test project and that makes not necessary to use build events.

sorry, I can't leave comments yet.

bniwredyc
+2  A: 

To expand on bniwredyc's answer, perhaps consider:

  • refactoring your web.config to reference a new config file like appSettings.config or similar.

  • modify your project's web.config to:

    <appSettings configSource="appSettings.config" />

  • modify your Unit Test project's app.config to use this file as well.

  • modify your post or pre-build events to copy just this file.

  • this also helps ease of deployment in Test/Staging/Prod

p.campbell
A: 

Ultimately, the web.config is an XML file. You could generate a schema to validate the sections required are present and that required values have been populated. Obviously, you couldn't contextually validate any sort of business logic that the configuration might contain, but you could use a combination of an XSD validation plus a lightweight class that is used to parse conditions within the file.

Used in conjunction with a copy pre-build event you actually create a very nice test harness for your production quality configurations.

joseph.ferris