Looking for TearDownAttribute on the stack is broken in .NET 8

Question

Background

I'm developing some NuGets that form an infrastructure for test automation based on NUnit that is used throughout my organization.

As part of it I have a method (let's call it OnTearDown) which should only be called from a method with [TearDown] attribute. In order to ensure that, OnTearDown calls the following method:

private static void AssertInTearDown(string methodName)
{
    var isInTearDown = IsMethodWithAttributeOnStack<TearDownAttribute>();

    if (!isInTearDown)
        throw new InvalidOperationException(
            $"Method {methodName} should only be called from a method with a [TearDown] attribute");
}

private static bool IsMethodWithAttributeOnStack<TAttribute>()
    where TAttribute : Attribute
{
    var stack = new StackTrace();
    return stack.GetFrames().Any(frame => frame.GetMethod()?.HasAttribute<TAttribute>() ?? false);
}

Some of my (older) clients call OnTearDown directly (from their [TearDown] decorated methods), but I also have a TestBase class which has its own [TearDown] method (also called TearDown) that most of the newer clients use.

While our clients we were using .NET 6, everything worked fine.

The problem

Recently we started migrating both our client projects and our NuGets to .NET 8. Some projects passed the migration seamlessly, but a few started encountering a very strange problem. When investigated, we saw that in these projects the problem occurs both with our older (.NET 6) packages and with the newer (.NET 8) ones, as long as the referencing project is .NET 8.

In these projects, some of the tests fail on tear down with the following error:

TearDown : System.InvalidOperationException : Method OnTearDown should only be called from a method with a [TearDown] attribute

Stack Trace:
at AssertInTearDown()
at OnTearDown()
at InvokeStub_TestBase.TearDown(Object, Object, IntPtr*)
at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)

Note: I modified the real stack trace here for the sake of clarity.

The most interesting and suspicious thing here is on the line

InvokeStub_TestBase.TearDown(Object, Object, IntPtr*)

My real class is called TestBase and not InvokeStub_TestBase, and it has no arguments (let along an IntPtr*...). I believe that .NET re-creates my TearDown method for some kind of optimization, and for some reason it doesn't have the [TearDown] attribute.

My questions

• If anyone can shed some light on what's going on here (e.g. what's that InvokeStub), that would be very helpful
• Any idea on how can I fix it?

Answer 1

In my experience, it's always risky for a method to make assumptions about how or or by whom it is invoked. On occasion it's unavoidable but it doesn't seem so in your case.

Base on @Klaus' answer, .NET 8.0 has changed the way in which base class teardowns are being called. Theoretically you could investigate exactly how and why this was done and solve your problem by giving the method even more knowledge of the details of how it is called. Theoretically...

I wonder, however if this is not an x/y question. Why would your method be called incorrectly? What exact problem are you trying to deal with here? In "normal" use of NUnit, any of your test, setup or teardown methods could be called directly by some code and would then not function correctly. Folks who write code for NUnit usually follow the instructions and don't do that or learn quickly that it's a bad idea. So, reconsider whether you really need to do this at all.

If you remain convinced that such a check is necessary, I suggest not relying on an implementation detail like the shape of the stack. Both dotnet and NUnit itself can easily evolve in ways that will break your assumptions. NUnit has changed how it calls methods 3 or 4 times since I started with it in 2002.

Your best bet with NUnit is probably to rely on information in the TestContext. If there is no TestContext (i.e. it's null) your method was not called by NUnit at all. If there is one, it can give you the name of the test method for which the teardown is already called and various other bits of info, which will probably allow you to decide if this is a valid call.

But first and foremost, consider whether this is actually something you need to worry about!