danielwertheim

danielwertheim


notes from a passionate developer

Developer that lives by the mantra "code is meant to be shared".

Share


Tags


Disclaimer

This is a personal blog. The opinions expressed here represent my own and not those of my employer, nor current or previous. All content is published "as is", without warranty of any kind and I don't take any responsibility and can't be liable for any claims, damages or other liabilities that might be caused by the content.

xUnit.Net - the life cycle of tests and testfixtures

Daniel WertheimDaniel Wertheim

Being used of NUnit and MSTest, xUnit (pre v2) comes with some slight differences. One that I initially had some troubles with when porting my tests, was the life cycle of tests and test fixtures. Most of the differences are very well documented at the xUnit CodePlex site. E.g. how xUnit makes use of a separate interface (IUseFixture<>) to mark a dependency on setup code for fixtures etc. How it also makes use of the constructors and Dispose methods of your test-classes and test-fixtures instead of relying on specific attributes that can be attached to arbitrary named methods. Now with regards taken to the life cycle, lets just do a simple test to see the call hierarchy of constructors, tests and disposal methods when using fixtures.

public class Class1 :  
    IDisposable,
    IUseFixture<MyFixture>
{
    public Class1()
    {
        Debug.WriteLine("cTor:Class1");
    }

    public void Dispose()
    {
        Debug.WriteLine("Dispose:Class1");
    }

    [Fact]
    public void TestOne()
    {
        Debug.WriteLine("TestOne");
    }

    [Fact]
    public void TestTwo()
    {
        Debug.WriteLine("TestTwo");
    }

    public void SetFixture(MyFixture data)
    {
        Debug.WriteLine("SetFixture:Class1");
    }
}

public class MyFixture : IDisposable  
{
    public MyFixture()
    {
        Debug.WriteLine("cTor:MyFixture");
    }

    public void Dispose()
    {
        Debug.WriteLine("Dispose:MyFixture");
    }
}

Running the two tests with the xUnit runner for ReSharper 8, the following call hierarchy will take place:

"cTor:MyFixture"
    "cTor:Class1"
        "SetFixture:Class1"
        "TestOne"
    "Dispose:Class1"

    "cTor:Class1"
        "SetFixture:Class1"
        "TestTwo"
    "Dispose:Class1"
"Dispose:MyFixture"

I’ve been getting questions on how to extract this info. Cause the above will e.g. output it in ReSharpers output, but not as one chunk of text, but instead one per test. My initial thought was to just hook in a TraceListener via app.config and just dump it to a log file. It turns out that the Debug.Listeners collection is “fiddled” with by xUnit. So in the test-fixture, your listener will be registrered, but in your test-class, it has been replaced. There’s probably a good design decision for this, personally I don’t like it. Anyway. You could make use of the BeforeAfterTestAttribute and ensure your listener is in place, but only in place for the test method, so instead, just register it in the constructor of your test-class: Debug.Listeners.Add(new SomeFooListener()); Then of course, in this simple case, you can also just step through the code.

Not sure if it’s off any use for you, but I use this blog to write for my self to, so now it’s here, so that I have somewhere to comeback to when I forget how it was.

Cheers,

//Daniel

Developer that lives by the mantra "code is meant to be shared".

Comments