Hi,
The SUT I am using looks in the app.config for a directory path. I am trying to test what happens if that path is invalid as part of a larger test suite. So at runtime, in the InitializeClassUnderTest method, I am rewriting that particular appsetting and creating an instance of the SUT, However, NCrunch has already loaded the app.config and that is the value that the SUT is finding, so my test fails.
Is there anyway to reload the appConfig in the NCrunch workspace or to configure NCrunch so that it does not load the app.config?
I appreciate an help I can get on this.
Thanks,
mmcdow
Remco NCrunch Developer
#7762
23 Sep 2015 22:50 UTC
Hi, thanks for posting!
Without attempting to hack/override the .NET configuration system, I broadly know of two ways to achieve what you're trying to do:
1. Create a new application domain, specifying the path to a different (modified) .config file, and using this application domain to call into your SUT. A major drawback of doing this is that NCrunch code coverage won't work inside this isolated application domain. It also makes your initialisation much more complex.
2. Wrap the application configuration objects behind an abstraction of some sort that can be controlled by your test code. This is highly recommended and it is the standard approach for overriding configuration settings during a test run. As long as the SUT depends on the abstraction and not on the .NET configuration system, you can easily inject whatever you like without .NET getting in the way.
Without attempting to hack/override the .NET configuration system, I broadly know of two ways to achieve what you're trying to do:
1. Create a new application domain, specifying the path to a different (modified) .config file, and using this application domain to call into your SUT. A major drawback of doing this is that NCrunch code coverage won't work inside this isolated application domain. It also makes your initialisation much more complex.
2. Wrap the application configuration objects behind an abstraction of some sort that can be controlled by your test code. This is highly recommended and it is the standard approach for overriding configuration settings during a test run. As long as the SUT depends on the abstraction and not on the .NET configuration system, you can easily inject whatever you like without .NET getting in the way.
Post a reply
Log in to reply.