如何将测试数据传递给 [TearDown] 之类的 NUnit 挂钩

Question

I have a testing framework that has been converted to heavily utilize NUnit [Parallelizable] . I used to store contextual test data in the base class of the [TestFixture] which NUnit orchestrates the hooks like [OneTimeSetUp] , [TearDown] , etc.

For example:

[Test]
public void GoToGoogle()
{
    var driver = new ChromeDriver();

    // do some stuff

    // Would like to pass data outside of test scope
    TestContext.CurrentContext.Test.Properties.Set("DriverUrl", driver.Url); // Obviously does not work

    Assert.Fail("This test should fail");
}

In the [TearDown] hook, I would like to get certain information about the test contextually. Because not everything is able to be handled nicely in asserts.

[TearDown]
public void TearDown()
{
    var url = TestContext.CurrentContext.Test.Properties["DriverUrl"].ToString();
    var msg = $"Test encountered an error at URL: {url}"
    TestAPI.PushResult(Result.Fail, msg);
}

The code above involving the TestContext does not work for obvious reasons, but I am wondering if there is a best practice that allows for me to pass data in this manner, keeping in mind respect to [Parallelizable] and that I cannot scope test data or dependencies to the [TestFixture]

Answer 1

You say "for obvious reasons" but I'll first spell out the reasons why you cannot effectively set a property on the current test through TestContext . After all, other people just might be reading this. :-)

The Obvious Part

TestContext.CurrentContext.Test does not return the internal representation of a test from inside NUnit. Doing so would allow users to break NUnit in a variety of ways. In particular, TestContext.CurrentContext.Test.Properties returns a copy of the properties used within NUnit.

That copy of the properties is not readonly , so you are able to set properties on it. For that reason, one might expect to be able to set it in the [Test] method and access the value in the [Teardown] .

Unfortunately, because of a minor implementation detail, that's not the case. In fact, each time you use TestContext.CurrentContext , an entirely new copy of the context is created. The only reason for this, I'm afraid, is that it was originally implemented that way and is a bit difficult to change in a non-breaking way.

As a result of this implementation detail, we lost an easy way for the three parts (SetUp, Test method, TearDown) of a test to communicate. Prior to the availability of parallel execution, it was possible to pass such information using members of the fixture class. That no longer works once tests are run in parallel.

Workarounds

1. Use Thread Local Storage to hold the retained information. SetUp, Test and Teardown all run on the same thread. Note that OneTimeSetUp and OneTimeTearDown will not generally use the same thread in a parallel execution environment.

2. If you are wiling to run fixtures in parallel but not individual test cases, then you can still use class members to retain information. As a further step, apply the SingleThreadedAttribute to your fixture, forcing all the code associated with it (including one-time setup and teardown) to run on the same thread.

If you have many fixtures, which can run in parallel, the second approach may actually give you a better performance trade-off than other approaches. Unfortunately, not everyone can use it - at least not without a major reorganization of their tests. You have to look at what your own tests are doing.

Permanent Solution

That would be to modify NUnit so that properties are both writable and shareable, at least within a single fixture instance. There have already been a few feature requests out there to do that on the NUnit GitHub project. I'm no longer active on the framework project, so I don't know what the plans are. However, I think I can say that it's not likely to happen before a major version change, ie NUnit 4.0.