reqnroll
[ScenarioDependencies] only called once per feature — breaks per-scenario test isolation
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
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 :)
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.
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.
