使用NUnit在不同的appdomain中运行单元测试

Question

I seem to be having an issue, the application we're using uses a Ninject kernel, and contains a particular configuration that's gathered with contents of the WCF call (username, token...).

Based on that a particular configuration the user is assigned rights on the app, this is shielded through a particular instance in the Ninject kernel.

We cannot just recompose the Ninject kernel, what we'd like to do is run a couple of Nunit tests, but run each of them in a separate app domain (recreating the kernel each time with different settings).

I've only found ways to run whole test projects in different app domains but not test per test.

Is there a way to solve this?

Unfortunately the Ninject configuration is not on our side, we have to 'live' with it this way.

Answer 1

I needed to do the the exact same thing, so I created a library which basically takes the current test and re-executes it in a new AppDomain. It's a nuget package called NUnit.ApplicationDomain and is open source .

Example Code:

[Test, RunInApplicationDomain]
public void Method()
{
  Console.WriteLine("I'm in a different AppDomain")
}

Answer 2

I don't think there is a way to solve it without re-writing parts of the NUnit code. It has been a while since I've been inside the NUnit code, but I am pretty sure the main app domain loading part has not changed.

NUnit typically uses two app domains. The default one that is created when NUnit is run and a separate one to load the test assemblies and the assemblies they reference. It's main reason in doing this is to allow the unloading of the test assemblies. You can't unload a dll, but you can unload an appdomain.

You might be able to run NUnit once per test and pass the test on the command line, but that's ugly and I'm not sure it will help.

It might also be possible to leverage Action Attributes in NUnit 2.6, but you are going to do a lot of work in there to do it.

You might also be able to create a new app domain in your setup method and call into it in each test. Awkward but possible.

I'm sorry I don't have a more complete answer.

Answer 3

I'm not entirely sure about your question. However it seems like you need some kind of a custom implementation. Did you consider custom test attributes? Then may be configure each attribute to run in a different App Domain? I'm just spinning up some ideas, but there may be better ways of doing this.