使用静态变量的单元测试C＃/。NET类（单元测试过程隔离）

Question

I've got a codebase that makes use of static variables in a number of cases where that makes sense, for example flagging that something's already run once since launch, etc etc.

Of course, this can lead to issues with unit testing whereupon suddenly order matters and the outcome of a test on a method of such a class may depend on whether other code has been hit before, etc. My understand of TestTools.UnitTesting is that whenever I run a set of unit tests, any within the same project run within the same process, thus any static state is maintained from test to test, whereas a Unit Test project boundary also implies a process boundary and thus, if I run 3 tests from project A then a fourth from project B, state is maintained from 1>2>3 (in whatever order they run) but then 4 is virgin and any static state is default.

So now my questions are two:

1) is my assessment correct that a unit test projects have a 1:1 relationship with processes when tests are run in a group (run all or run selected), or is there more nuance there that I'm missing?

2) Regardless, if I have a test that definitely needs fresh, default static state for the custom objects it uses and tests, do I have a more elegant option for creating it than giving it its own test project?

Answer 1

Your assessment is correct as far as I know -- the assembly is loaded at the start of the test process, and any static state is maintained throughout the tests.

You should always start with a "fresh" state. Unit tests should be able to be run in any order, with no dependencies whatsoever. The reason is because your tests need to be reliable -- a test should only ever fail for one reason: The code it's testing changed. If you have tests that depend on other tests, then you can easily end up with one test failing and "breaking the chain" such that a dozen other tests fail.

You can use the TestInitialize attribute to define a method that will run before every test that will reset the state to the baseline.

Another way to enable this is to wrap your static state into a singleton, then put a "back door" into the singleton so that you can inject an instance of the singleton class, allowing you to configure the state of the application as part of arranging your test.

Answer 2

Statics are not actually per process, but per application domain, represented by the AppDomain class. A single process can have several AppDomains. AppDomains have their own statics, can provide sandboxing to partially trusted code, and can be unloaded allowing newer versions of the same assembly to be hot swapped without restarting the application.

Your test runner is likely creating a new AppDomain per test assembly so each assembly gets its own static variables. You can create an AppDomain to do the same on the fly. This is not typically great for pure unit tests, but I've had to work with "rude" libraries that do all kinds of static initialization and caching that cannot be cleaned out or reset. In those sorts of integration scenarios it is very useful.

You can use this helper to run a simple delegate:

public static class AppDomainHelper
{
    public static void Run(Action action)
    {
        var domain = AppDomain.CreateDomain("test domain");
        try
        {
            domain.DoCallBack(new CrossAppDomainDelegate(action));
        }
        finally
        {
            AppDomain.Unload(domain);
        }
    }
}

One caution is that the delegate action passed to Run cannot have any captured variables (as in from a lambda). That doesn't work because the compiler will generate a hidden class that is not serializable and so it cannot pass through an AppDomain boundary.

Answer 3

If you're not looking to test global state, but rather what you do with values you get from global state, you can work around it.

Consider this simple class definition that uses some static property.

public class Foo
{
   public int Bar(int baz)
   {
       return baz + GlobalState.StaticValue;
   }
}

You can refactor it like this.

public class Foo
{
    public virtual int GetGlobalStaticValue
    {
        return GlobalState.StaticValue;
    }

    public virtual int Bar(int baz)
    {
        return baz + this.GetGlobalStaticValue();
    }
}

I added virtual s to the method definitions because that's particular to Rhino Mocks, but you get the idea - while running live, your class will pull global state as it does now, but it gives you the hooks to mock out the values that will be returned in your test scenario.