[ScenarioDependencies] only called once per feature — breaks per-scenario test isolation

[sebastien-fresse-idslplc]

Reqnroll Version

2.4.1

Which test runner are you using?

MSTest

Test Runner Version Number

dotnet test, Visual Studio Test Explorer 2022

.NET Implementation

.NET 9.0

Test Execution Method

Visual Studio Test Explorer

Content of reqnroll.json configuration file

{
"$schema": "https://schemas.reqnroll.net/reqnroll-config-latest.json",

"bindingAssemblies": [

]
}

Issue Description

❗️ Problem summary

After migrating from SolidToken.SpecFlow.DependencyInjection to Reqnroll.Microsoft.Extensions.DependencyInjection, we noticed that [ScenarioDependencies(ScopeLevelType.Scenario)] is only invoked once per test run, not per scenario.

This breaks the expected behavior where each scenario should receive a freshly built IServiceProvider.

This issue occurs:

• In Visual Studio

• With dotnet test

• Even when the method is annotated properly with ScopeLevelType.Scenario

---

⚠️ Impact

• 💣 Breaks test isolation

• 🧪 Prevents reseeding in-memory databases (duplicate key errors)

• 🔧 Makes it impossible to vary mocks or services between scenarios

• 🐛 Inconsistent with the documentation and intended purpose of ScopeLevelType.Scenario

---

✅ Expected behavior

[ScenarioDependencies(ScopeLevelType.Scenario)] should be executed once per scenario, with a fresh IServiceProvider or ILifetimeScope built each time.

---

---

💬 Additional notes

This behavior works correctly under SolidToken.SpecFlow.DependencyInjection.

Steps to Reproduce

🔄 Steps to reproduce
Create a test project with Reqnroll + Microsoft.Extensions.DependencyInjection plugin

Add [ScenarioDependencies(ScopeLevel = ScopeLevelType.Scenario)] on a method

Add Console.WriteLine(...) inside the method

Create a .feature file with 2+ scenarios

Run with dotnet test or from Test Explorer

💥 Result:
CreateServices() is only called once — the same ServiceProvider is reused across all scenarios.

Link to Repro Project

No response

[304NotModified]

While we are working on https://github.com/orgs/reqnroll/discussions/472, a PR would be accepted.

You could try using Copilot, if you test it yourself and review all the generated code :)

[kamranayub]

Actually, I think this may be working as designed.

ScopeLevelType changes the .AddScoped scope-level (which is scenario-level by default anyway), not when the [ScenarioDependencies] gets called. I learned this too and thought initially it was a bug. But now, it makes sense -- and actually makes my life easier. Because now you know it only gets called once, you can set up configuration builder and then any singletons + scenario-scoped services once.

[gasparnagy]

In that case, maybe we should close this issue as "not planned". I fear that (regardless it is helpful or not) changing this would cause quite much issues with the existing usages of the MSDI integration.

Please reopen if you disagree.

[AidenFuller]

I've run into this precise issue as well. I understand what the current behaviour is setup to do, but I think having another parameter which controls when a fresh service provider is actually created would be a useful feature to have as well here, especially for when services are registered in applications via a wrapper extension (e.g. .AddSamplePackageServices()) for which you can't control the scoping.

Perhaps some other property on the ScenarioDependencies attribute to create this would be useful as well?
e.g. ScenarioDependencies(ContainerLifetime = ContainerLifetimeType.Feature) defaulting to ContainerLifetimeType.TestRun

If this is an acceptable usage, I'm happy to do my best to implement this in a PR

[gasparnagy]

I've run into this precise issue as well. I understand what the current behaviour is setup to do, but I think having another parameter which controls when a fresh service provider is actually created would be a useful feature to have as well here, especially for when services are registered in applications via a wrapper extension (e.g. .AddSamplePackageServices()) for which you can't control the scoping.

Perhaps some other property on the ScenarioDependencies attribute to create this would be useful as well? e.g. ScenarioDependencies(ContainerLifetime = ContainerLifetimeType.Feature) defaulting to ContainerLifetimeType.TestRun

If this is an acceptable usage, I'm happy to do my best to implement this in a PR

If you can make a change that is opt-in, so the current usage is not affected but there is an extra property, etc to supports the requested model, then I don't think it would be a problem to add it. Try making a prototype and submit for a pre-review if you could figure out something.

[AidenFuller]

I have created a PR with what I believe is a working prototype here: #998

[gasparnagy]

I have created a PR with what I believe is a working prototype here: #998

Thx! I will try to get some time and do a review on that in the upcoming days.