Reqnroll vs SpecFlow: Migration and Differences

In 2023, Tricentis -- the company that acquired SpecFlow -- announced that SpecFlow would be discontinued in favor of their commercial product, SpecFlow+. The open-source SpecFlow project was effectively end-of-lifed. A group of maintainers and community contributors responded by forking the codebase and creating Reqnroll, keeping the spirit of the original project alive under an Apache 2.0 license.

If your team runs SpecFlow today, you are on a framework with no future security patches, no new .NET runtime support, and no bug fixes. Reqnroll is the migration path.

What Changed Between SpecFlow and Reqnroll

The behavioral differences are minimal by design. Reqnroll intentionally preserves API compatibility to make migration as frictionless as possible. What actually changed:

Licensing: SpecFlow was MIT. Reqnroll is Apache 2.0. Both are permissive. Reqnroll has no commercial tier, no feature gating, no telemetry by default.

Namespace: The primary breaking change is the namespace. TechTalk.SpecFlow becomes Reqnroll. Every using statement that references SpecFlow needs to be updated.

NuGet packages: SpecFlow packages (SpecFlow, SpecFlow.NUnit, etc.) are replaced with Reqnroll equivalents (Reqnroll, Reqnroll.NUnit, etc.).

IDE tooling: The SpecFlow Visual Studio extension no longer receives updates. Reqnroll ships its own extension (Reqnroll.VisualStudio) which is actively maintained and works with Visual Studio 2022.

Configuration: SpecFlow used specflow.json or App.config. Reqnroll uses reqnroll.json. The schema is nearly identical; keys are the same.

Async step support: Reqnroll added first-class async step definition support, which SpecFlow had inconsistent behavior around.

Migration: Step by Step

1. Update NuGet packages

Remove all SpecFlow packages and add Reqnroll equivalents. In your .csproj:

<!-- Remove these -->
<PackageReference Include="SpecFlow" Version="3.9.74" />
<PackageReference Include="SpecFlow.NUnit" Version="3.9.74" />
<PackageReference Include="SpecFlow.Tools.MsBuild.Generation" Version="3.9.74" />

<!-- Add these -->
<PackageReference Include="Reqnroll" Version="2.1.0" />
<PackageReference Include="Reqnroll.NUnit" Version="2.1.0" />

2. Replace namespaces

Run a global find-and-replace across all .cs files:

TechTalk.SpecFlow  ->  Reqnroll

This covers using directives, attribute references, and type references like ScenarioContext, FeatureContext, Table, and IObjectContainer.

In most projects this is the only code change required. The types themselves retain the same names and signatures.

3. Rename configuration file

If you use specflow.json, rename it to reqnroll.json. Update the content root key:

// specflow.json (old)
{
  "specFlow": {
    "stepAssemblies": [
      { "assembly": "MyApp.SharedSteps" }
    ]
  }
}

// reqnroll.json (new)
{
  "reqnroll": {
    "stepAssemblies": [
      { "assembly": "MyApp.SharedSteps" }
    ]
  }
}

If you used App.config with a <specFlow> section, the equivalent in reqnroll.json is straightforward to translate. The Reqnroll documentation includes a full mapping.

4. Update the Visual Studio extension

Uninstall the SpecFlow extension. Install Reqnroll for Visual Studio 2022 from the Visual Studio Marketplace. This restores step navigation, Gherkin syntax highlighting, and step stub generation.

5. Verify the build

dotnet build
dotnet test

If any compilation errors remain, they will point to specific types or attributes that still reference TechTalk.SpecFlow. The fix is always the same namespace replacement.

Compatibility Notes

Feature files: .feature files require zero changes. Gherkin syntax is unchanged.

Step definitions: Beyond the namespace change, step definition logic is identical. All attributes ([Given], [When], [Then], [BeforeScenario], [AfterScenario]) work the same way.

Plugin ecosystem: Most SpecFlow plugins that target the open-source layer (not SpecFlow+) are compatible or have Reqnroll-native replacements. The Reqnroll project maintains a compatibility list in its GitHub repository.

LivingDoc: SpecFlow+ LivingDoc (the HTML test report generator) was a commercial product. Reqnroll's community has produced Reqnroll.Contrib.LivingDoc as an open-source alternative. Pickles is another option that generates documentation from .feature files independently.

Parallel execution: Reqnroll's default parallel execution model is the same as SpecFlow's. Thread isolation and [assembly: Parallelizable] behave identically.

Should You Migrate Now

The answer is yes, but the urgency depends on your .NET version. If you are still on .NET 6 (end of life November 2024) or .NET 7, SpecFlow likely still runs. Once you move to .NET 8 or .NET 9, SpecFlow compatibility is not guaranteed, and you will hit runtime or build tool issues with no upstream fix available.

Reqnroll is not a rewrite. The migration cost for a typical project is an hour of package swaps and namespace replacements. The ongoing cost of staying on SpecFlow is compounding debt.

After migrating, run the full test suite once to establish a green baseline, then pin Reqnroll to a specific version in your .csproj to avoid unintentional upgrades in CI.