With NUnit 4.x, "Only static OneTimeSetUp and OneTimeTearDown are allowed for InstancePerTestCase mode"

[SeanKilleen]

Reqnroll Version

2.2.1

Which test runner are you using?

NUnit

Test Runner Version Number

4.3.2

.NET Implementation

.NET 9.0

Test Execution Method

Other – PLEASE SPECIFY

Content of reqnroll.json configuration file

No file in use to my knowledge.

Issue Description

Firstly, I absolutely love the way you're stepping in to support the community with this tool and I look forward to promoting and supporting it however I can.

---

This seems similar to #320 except I'm still experiencing the issue after installing Reqnroll v2.2.1.

Background

• I'm in the process of replacing SpecFlow with Reqnroll (have I mentioned that I absolutely love you for this?)
• My current project uses NUnit 4.3.2 along with TestContainers for some unrelated standard unit tests we have that test IronPDF.
• I'm removing SpecFlow.NUnit and SpecFlow.Tools.MSBuild.Generation and replacing them with the latest (2.2.1) of Reqnroll.NUnit and Reqnroll.Tools.MsBuild.Generation.

Problem

The tests that are unrelated to Reqnroll have begun to fail.

The output of these tests in that branch is now:

OneTimeSetUp: System.InvalidOperationException : Only static OneTimeSetUp and OneTimeTearDown are allowed for InstancePerTestCase mode.

Steps to Reproduce

See repro project below which includes a very small reproduction project.

Link to Repro Project

https://github.com/sct-software/Reqnroll-379-reproduction

[SeanKilleen]

While I work on the smaller reproduction, some information that may help --

It looks like in NUnit.AssemblyHooks.template.cs, the FixtureLifeCycle is set to InstancePerTestCase.

I'm not sure if this is intended, but it conflicts with the NUnit default, which according to the docs is SingleInstance.

Because this assembly-level attribute is set, I think my tests are picking up the non-default behavior and NUnit is therefore expecting them to adhere to the static constraint.

[SeanKilleen]

You can find a basic reproduction at https://github.com/sct-software/Reqnroll-379-reproduction

There are two tags -- the commit prior to the issue being introduced, and then adding Reqnroll.NUnit which introduces the issue. The current commit on the main branch has the issue reproduced.

[SeanKilleen]

An quick workaround for this is setting [FixtureLifeCycle(LifeCycle.SingleInstance)] on our non-Reqnroll test class -- this resolved the issue.

So I'd suggest the outcome of this issue could be:

• A change in the assembly level setting to the NUnit default of SingleInstance
• Or, a note on https://docs.reqnroll.net/latest/integrations/nunit.html describing this behavior, what it might cause, and how users might want to mitigate it.

I'm happy to do a PR for either of those.

[obligaron]

Thanks for the good analysis and reproduction 🙂 .

This change was introduced when we supported parallel execution at the scenario/method level (see #277).

We could fix this by adding the FixtureLifeCycle to each generated class instead of doing it globally.

[SeanKilleen]

Sounds good, I'll do the PR for it, today if I can. Not mad if anyone beats me to it :)

[dqwork]

Hi, any update on this please? Its quite a confusing problem to hit, the quick fix is helpful - but there's a potential for 100s of test classes to need that attribute adding now which feels like the wrong approach

[SeanKilleen]

@dqwork they've been kindly waiting on me to complete a PR that I've only just started: #388

But I had some family medical issues come up and it has been long-delayed.

I don't mind if anyone else takes over the PR or creates their own to move it to the finish line.

[gasparnagy]

Taking over #388 as #432

[dqwork]

Thanks for the quick turn around there.

When is this likely to be released?

[gasparnagy]

Early next week, I hope.

[gasparnagy]

Released in 2.3.0: https://github.com/reqnroll/Reqnroll/releases/tag/v2.3.0

[dqwork]

Thank you!