My code is using a third party library that employ a singleton pattern deep down inside it. On first access, the library uses windows environment variables to identify a configuration folder from which it is loaded.
However, I want to run against different folders in different sets of unit tests. Ideally I would specify the configuration folder for every unit test class or somesuch.
The third party library is a huge object model and my code is simply a set of extension methods on top of of them. I can see no easy way of mocking out the entire library.
Is there any way that I can create a new appdomain per test class? I know that load tests has a setting for creating domains between running test assemblies. In my case that would be a lot of assemblies and I’m not quite sure if/how this setting can be set on unit test testrunner.
Alternatively, I am considering purchasing either Typemock Isolator or JustMock so that I can make the singleton return a “null”, resulting in the 3rd party library loading a new one. I’ve looked at the decompiled code and it appears that it could achieve the desired result. Of, course, there may be more “goodies” hidden there.
These are contrived approaches. What I really would like is to “flush” the complete appdomain between tests, test classes or test assemblies.
I am willing to sacrifice speed when automated tests need to switch configuration folders. The red-green-refactor cycle probably wont include multiple configuration folders.
Any suggestions on how to achieve this?
EDIT
I just discovered that different test assemblies will result in singletons being erased. Therefore, it is possible to organize test assemblies according to what configuration they run on instead of by dependency or problem domain which targeted by the tests.
Spreading out in different test assemblies.
Spreading the unit testing class into different test assemblies will result in new appdomains being created by the testrunner, and thus singletons will be erased.
Therefore, it is possible to organize test assemblies according to what configuration they run on instead of by dependency or problem domain which targeted by the tests.
This solution may not be for everyone, though, for the following reasons:
This is in danger of creating a messy solution with an abundance of test projects (for the various test data). The resulting structure is contrary to standard pracitce of having unit tests organized per component and problem domain.
I am not touching the data in the singleton. It is just a backing data reference library. A prime directive of unit tests is that they shall not affect each other or require a particular sequence.
Another prime directive of unit tests is that they shall run fast. Luckily, I will not have to run against multiple test configurations in the normal red->green->refactor cycle. The larger suite of test assemblies will be regression tests.