Blog

SpecFlow to Reqnroll: A Step-by-Step Migration Guide

by Rajesh K | Jun 20, 2025 | Automation Testing, Blog, Latest Post | 3 comments

Behavior-Driven Development (BDD) has become integral to automation testing in .NET projects, and SpecFlow has long been a go-to framework for writing Gherkin scenarios in C#. However, SpecFlow’s development has slowed in recent years, and it has lagged in support for the latest .NET versions. Enter Reqnroll, a modern BDD framework that picks up where SpecFlow left off. Reqnroll is essentially a fork of SpecFlow’s open-source core, rebranded and revitalized to ensure continued support and innovation. This means teams currently using SpecFlow can transition to Reqnroll with minimal friction while gaining access to new features and active maintenance. The SpecFlow to Reqnroll migration path is straightforward, making it an attractive option for teams aiming to future-proof their automation testing efforts.

In this comprehensive guide, we’ll walk QA engineers, test leads, automation testers, and software developers through migrating from SpecFlow to Reqnroll, step by step. You’ll learn why the shift is happening, who should consider migrating, and exactly how to carry out the migration without disrupting your existing BDD tests. By the end, you’ll understand the key differences between SpecFlow and Reqnroll, how to update your projects, and how to leverage Reqnroll’s improvements. We’ll also provide real-world examples, a comparison table of benefits, and answers to frequently asked questions about SpecFlow to Reqnroll. Let’s ensure your BDD tests stay future-proof and rock n’ roll with Reqnroll!

Why Migrate from SpecFlow to Reqnroll?

If you’ve been relying on SpecFlow for BDD, you might be wondering why a migration to Reqnroll is worthwhile. Here are the main reasons teams are making the switch from SpecFlow to Reqnroll:

• Active Support and Updates: SpecFlow’s support and updates have dwindled, especially for newer .NET releases. Reqnroll, on the other hand, is actively maintained by the community and its original creator, ensuring compatibility with the latest .NET 6, 7, 8, and beyond. For example, SpecFlow lacked official .NET 8 support, which prompted the fork to Reqnroll to fill that gap. With Reqnroll, you benefit from prompt bug fixes and feature enhancements backed by an engaged developer community.
• Enhanced Features: Reqnroll extends SpecFlow’s capabilities with advanced tools for test management and reporting. Out of the box, Reqnroll supports generating detailed test execution reports and linking tests to requirements for better traceability. Teams can organize and manage test cases more efficiently within Reqnroll, enabling full end-to-end visibility of BDD scenarios. These enhancements go beyond what SpecFlow offered by default, making your testing suite more robust and informative.
• Seamless Integration: Reqnroll is designed to work smoothly with modern development tools and CI/CD pipelines. It integrates with popular CI servers (Jenkins, Azure DevOps, GitHub Actions, etc.) and works with IDEs like Visual Studio and VS Code without hiccups. There’s even a Reqnroll Visual Studio Extension that supports both SpecFlow and Reqnroll projects side by side, easing the transition for developers. In short, Reqnroll slots into your existing development workflow just as easily as SpecFlow did if not more so.
• High Compatibility: Since Reqnroll’s codebase is directly forked from SpecFlow, it maintains a high level of backward compatibility with SpecFlow projects. Everything that worked in SpecFlow will work in Reqnroll in almost the same way, with only some namespaces and package names changed. This means you won’t have to rewrite your feature files or step definitions from scratch – migration is mostly a find-and-replace job (as we’ll see later). The learning curve is minimal because Reqnroll follows the same BDD principles and Gherkin syntax you’re already used to.
• Community-Driven and Open Source: Reqnroll is a community-driven open-source project, free to use for everyone. It was created to “reboot” SpecFlow’s open-source spirit and keep BDD accessible. The project invites contributions and has options for companies to sponsor or subscribe for support, but the framework itself remains free. By migrating, you join a growing community investing in the tool’s future. You also eliminate reliance on SpecFlow’s trademarked, closed-source extensions – Reqnroll has already ported or is rebuilding those essential extras (more on that in the comparison table below).

In summary, migrating to Reqnroll lets you continue your BDD practices with a tool that’s up-to-date, feature-rich, and backed by an active community. Next, let’s look at how to plan your migration approach.

Planning Your SpecFlow to Reqnroll Migration

Before migrating, choose between two main approaches:

1. Quick Switch with Compatibility Package:

Use the Reqnroll.SpecFlowCompatibility NuGet package for a minimal-change migration. It lets you continue using the TechTalk.SpecFlow namespace while running tests on Reqnroll. This option is ideal for large projects aiming to minimize disruption—just swap out NuGet packages and make small tweaks. You can refactor to Reqnroll-specific namespaces later.

2. Full Migration with Namespace Changes:

This involves fully replacing SpecFlow references with Reqnroll ones (e.g., update using TechTalk.SpecFlow to using Reqnroll). Though it touches more files, it’s mostly a search-and-replace task. You’ll remove SpecFlow packages, add Reqnroll packages, and update class names. This cleaner, long-term solution avoids reliance on compatibility layers.

Which path to choose?

For a quick fix or large codebases, the compatibility package is fast and easy. But for long-term maintainability, a full migration is recommended. Either way, back up your project and use a separate branch to test changes safely.

Now, let’s dive into the step-by-step migration process.

SpecFlow to Reqnroll Migration Steps

Moving from SpecFlow to Reqnroll involves a series of straightforward changes to your project’s packages, namespaces, and configuration. Follow these steps to transition your BDD tests:

Step 1: Update NuGet Packages (Replace SpecFlow with Reqnroll)

The first step is to swap out SpecFlow’s NuGet packages for Reqnroll’s packages. Open your test project’s package manager (or .csproj file) and make the following changes:

• Remove SpecFlow Packages: Uninstall or remove any NuGet references that start with SpecFlow. This includes the main SpecFlow package and test runner-specific packages like SpecFlow.NUnit, SpecFlow.MsTest, or SpecFlow.xUnit. Also, remove any CucumberExpressions.SpecFlow.* packages, as Reqnroll has built-in support for Cucumber Expressions.
• Add Reqnroll Packages: Add the corresponding Reqnroll package for your test runner: for example, Reqnroll.NUnit, Reqnroll.MsTest, or Reqnroll.xUnit (matching whichever test framework your project uses). These packages provide Reqnroll’s integration with NUnit, MSTest, or xUnit, just like SpecFlow had. If you opted for the compatibility approach, also add Reqnroll.SpecFlowCompatibility, which ensures your existing SpecFlow code continues to work without immediate refactoring.

After updating the package references, your project file will list Reqnroll packages instead of SpecFlow. For instance, a .csproj snippet for an MSTest-based BDD project might look like this after the change:

<ItemGroup>
    <!-- Test framework dependencies -->
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.X.X" />
    <PackageReference Include="MSTest.TestAdapter" Version="3.X.X" />
    <PackageReference Include="MSTest.TestFramework" Version="3.X.X" />
    <!-- Reqnroll packages (replaced SpecFlow packages) -->
    <PackageReference Include="Reqnroll.MsTest" Version="2.0.0" />
    <PackageReference Include="Reqnroll.SpecFlowCompatibility" Version="2.0.0" />
    <PackageReference Include="Reqnroll.SpecFlowCompatibility.Actions.Selenium" Version="2.0.0" />
</ItemGroup>

Once these package changes are made, restore the NuGet packages and build the project. In many cases, this is the only change needed to get your tests running on Reqnroll. However, if you did the full migration path (not using the compatibility package), you’ll have some namespace adjustments to handle next.

Step 2: Replace Namespaces and References in Code

With the new Reqnroll packages in place, the next step is updating your code files to reference Reqnroll’s namespaces and any renamed classes. This is primarily needed if you opted for a full migration. If you installed the Reqnroll.SpecFlowCompatibility package, you can skip this step for now, as that package allows you to continue using the TechTalk.SpecFlow namespace temporarily.

For a full migration, perform a global find-and-replace in your solution:

• Namespaces: Replace all occurrences of TechTalk.SpecFlow with Reqnroll. This applies to using directives at the top of your files and any fully qualified references in code. Make sure to match case and whole words so you don’t accidentally alter feature file text or other content. Most of your step definition classes will have using TechTalk.SpecFlow; this should become using Reqnroll; (or in some cases using Reqnroll.Attributes;) to import the [Binding] attribute and other needed types in the Reqnroll library.
• Class and Interface Names: Some SpecFlow-specific classes or interfaces have been renamed in Reqnroll. For example, ISpecFlowOutputHelper (used for writing to test output) is now IReqnrollOutputHelper. Similarly, any class names that contained “SpecFlow” have been adjusted to “Reqnroll”. Use find-and-replace for those as well (e.g., search for ISpecFlow and SpecFlowOutput, etc., and replace with the new names). In many projects, the output helper interface is the main one to change. If you encounter compile errors about missing SpecFlow types, check if the type has a Reqnroll equivalent name and update accordingly.
• Attributes: The [Binding] attribute and step definition attributes ([Given], [When], [Then]) remain the same in usage. Just ensure your using statement covers the namespace where they exist in Reqnroll (the base Reqnroll namespace contains these, so using Reqnroll is usually enough). The attribute annotations in your code do not need to be renamed, for example, [Given(“some step”)] is still [Given(“some step”)]. The only difference is that behind the scenes, those attributes are now coming from Reqnroll’s library instead of SpecFlow’s.

After these replacements, build the project again. If the build succeeds, great – your code is now referencing Reqnroll everywhere. If there are errors, they typically fall into two categories:

Missing Namespace or Type Errors:

If you see errors like a reference to TechTalk.SpecFlow still lingering or a missing class, double-check that you replaced all references. You might find an edge case, such as a custom hook or attribute that needed an additional using Reqnroll.Something statement. For instance, if you had a custom value retriever or dependency injection usage with SpecFlow’s BoDi container, note that BoDi now lives under Reqnroll.BoDi, you might add using Reqnroll.BoDi; in those files.

SpecFlow v3 to v4 Breaking Changes:

Reqnroll is based on the SpecFlow v4 codebase. If you migrated from SpecFlow v3 (or earlier), some breaking changes from SpecFlow v3→v4 could surface (though this is rare and usually minor). One example is Cucumber Expressions support. Reqnroll supports the more readable Cucumber Expressions for step definitions in addition to regex. Most existing regex patterns still work, but a few corner cases might need adjustment (e.g., Reqnroll might interpret a step pattern as a Cucumber Expression when you meant it as a regex). If you get errors like “This Cucumber Expression has a problem”, you can fix them by slightly tweaking the regex (for example, adding ^…$ anchors to force regex mode or altering escape characters) as described in the Reqnroll docs. These cases are uncommon but worth noting.

In general, a clean build at this stage means all your code is now pointing to Reqnroll. Your Gherkin feature files remain the same – steps, scenarios, and feature definitions don’t need changing (except perhaps to take advantage of new syntax, which is optional). For example, you might later decide to use Cucumber style parameters ({string}, {int}, etc.) in your step definitions to replace complex regex, but this is not required for migration it’s just a nice enhancement supported by Reqnroll.

Example: Imagine a SpecFlow step definition class for a login feature. Before migration, it may have looked like:

// Before (SpecFlow)
using TechTalk.SpecFlow;

[Binding]
public class LoginSteps
{
    [Given(@"the user is on the login page")]
    public void GivenTheUserIsOnTheLoginPage() {
        // ... (implementation)
    }
}

After migration to Reqnroll, with namespaces replaced, it becomes:

// After (Reqnroll)
using Reqnroll;

[Binding]
public class LoginSteps
{
    [Given("the user is on the login page")]
    public void GivenTheUserIsOnTheLoginPage() {
        // ... (implementation)
    }
}

As shown above, the changes are minimal – the using now references Reqnroll and the rest of the code remains functionally the same. We removed the @ in the given regex because in Reqnroll you could choose to use a simpler Cucumber expression (here the quotes indicate a string), but even if we kept the regex it would still work. This demonstrates how familiar your code will look after migration.

Step 3: Adjust Configuration Settings

SpecFlow projects often have configuration settings in either a specflow.json file or an older App.config/specFlow section. Reqnroll introduces a new JSON config file named reqnroll.json for settings, but importantly, it is designed to be backwards compatible with SpecFlow’s config formats. Depending on what you were using, handle the configuration as follows:

• If you used specflow.json: Simply rename the file to reqnroll.json. The content format inside doesn’t need to change much, because Reqnroll accepts the same configuration keys. However, to be thorough, you can update two key names that changed:
• stepAssemblies is now called bindingAssemblies in Reqnroll (this is the setting that lists additional assemblies containing bindings).
• If you had bindingCulture settings, note that in Reqnroll those fall under a language section now (e.g., language: { binding: “en-US” }).
• These old names are still recognized by Reqnroll for compatibility, so your tests will run even if you don’t change them immediately. But updating them in the JSON is recommended for clarity. Also, consider adding the official JSON schema reference to the top of reqnroll.json (as shown in Reqnroll docs) for IntelliSense support.

If you used an App.config (XML) for SpecFlow: Reqnroll’s compatibility package can read most of the old App.config settings without changes, except one line. In the of App.config, the SpecFlow section handler needs to point to Reqnroll’s handler. You should replace the SpecFlow configuration handler line with the Reqnroll one, for example:

<configSections>
    <!-- Old: <section name="specFlow" type="TechTalk.SpecFlow.Configuration.ConfigurationSectionHandler, TechTalk.SpecFlow" /> -->
    <section name="specFlow" type="Reqnroll.SpecFlowCompatibility.ReqnrollPlugin.ConfigurationSectionHandler, Reqnroll.SpecFlowCompatibility.ReqnrollPlugin" />
</configSections>

• The above change is only needed if you still rely on App.config for settings. Going forward, you might migrate these settings into a reqnroll.json for consistency, since JSON is the modern approach. But the compatibility package ensures that even if you leave most of your App.config entries as-is, Reqnroll will pick them up just fine (after that one section handler tweak).
• Default configuration: If you had no custom SpecFlow settings, then Reqnroll will work with default settings out of the box. Reqnroll will even honor a specflow.json left in place (thanks to compatibility), so renaming to reqnroll.json is optional but encouraged for clarity.

After updating the config, double-check that your reqnroll.json (if present) is included in the project (Build Action = Content if needed) so it gets copied and recognized at runtime. Configuration differences are minor, so this step is usually quick.

Step 4: Run and Verify Your Tests

Now it’s the moment of truth, running your BDD tests on Reqnroll. Execute your test suite as you normally would (e.g., via dotnet test on the command line, or through Visual Studio’s Test Explorer). Ideally, tests that were green in SpecFlow should remain green under Reqnroll without any changes to the test logic. Reqnroll was designed to preserve SpecFlow’s behavior, so any failing tests likely indicate a small oversight in migration rather than a fundamental incompatibility.

If all tests pass, congratulations, you’ve successfully migrated to Reqnroll! You should see in the test output or logs that Reqnroll is executing the tests now (for example, test names might be prefixed differently, or the console output shows Reqnroll’s version). It’s a good idea to run tests both locally and in your CI pipeline to ensure everything works in both environments.

Troubleshooting: In case some tests fail or are behaving oddly, consider these common post-migration tips:

• Check for Missed Replacements: A failing step definition could mean the binding wasn’t picked up. Perhaps a using TechTalk.SpecFlow remained in a file, or a step attribute regex now conflicts with Cucumber expression syntax as mentioned earlier. Fixing those is usually straightforward by completing the find/replace or adjusting the regex.
• Cucumber Expression Pitfalls: If a scenario fails with an error about no matching step definition, yet the step exists, it might be due to an edge-case interpretation of your regex as a Cucumber Expression. Adding ^ and $ around the pattern in the attribute tells Reqnroll to treat it strictly as regex. Alternatively, adopt the cucumber expression format in the attribute. For example, a SpecFlow step like [When(@”the user enters (.*) and (.*)”)] could be rewritten as [When(“the user enters {string} and {string}”)] to leverage Reqnroll’s native parameter matching. Both approaches resolve ambiguity.
• MSTest Scenario Outlines: If you use MSTest as your test runner, be aware that Reqnroll generates scenario outlines as individual data-driven test cases by default (using MSTest’s data row capability). In some setups, this can cause the test explorer to show scenario outline scenarios as “skipped” if not configured properly. The fix is to adjust a setting to revert to SpecFlow’s older behavior: set allowRowTests to false for Reqnroll’s MSTest generator (this can be done in reqnroll.json under the generator settings). This issue and solution are documented in Reqnroll’s migration guide. If using NUnit or xUnit, scenario outlines should behave as before by default.
• Living Documentation: SpecFlow’s LivingDoc (HTML living documentation generator) is not directly available in Reqnroll yet, since the SpecFlow+ LivingDoc tool was closed-source. If your team relies on living documentation, note that the Reqnroll community is working on an open-source alternative. In the meantime, you can use the SpecFlow+ LivingDoc CLI as a workaround with Reqnroll’s output, per the discussion in the Reqnroll project. This doesn’t affect test execution, but it’s something to be aware of post-migration for your reporting process.

Overall, if you encounter issues, refer to the official Reqnroll documentation’s troubleshooting and “Breaking Changes since SpecFlow v3” sections, they cover scenarios like the above in detail. Most migrations report little to no friction in this verification step.

Step 5: Leverage Reqnroll’s Enhanced Features (Post-Migration)

Migrating to Reqnroll isn’t just a lateral move, it’s an opportunity to level up your BDD practice with new capabilities. Now that your tests are running on Reqnroll, consider taking advantage of these improvements:

• Advanced Test Reporting: Reqnroll can produce rich test reports, including HTML reports that detail each scenario’s outcome, execution time, and more. For example, you can integrate a reporting library or use Reqnroll’s API to generate an HTML report after your test run. This provides stakeholders with a clear view of test results beyond the console output. Visual idea: an image of a sample Reqnroll test report showing a summary of scenarios passed/failed.
• Requirements Traceability: You can link your scenarios to requirements or user stories using tags. For instance, tagging a scenario with @Requirement:REQ-101 can associate it with a requirement ID in your management tool. Reqnroll doesn’t require a separate plugin for this; it’s part of the framework’s ethos (even the name “Reqnroll” hints at starting BDD from requirements). By leveraging this, you ensure every requirement has tests, and you can easily gather which scenarios cover which requirements. This is a great way to maintain traceability in agile projects.
• Data-Driven Testing Enhancements: While SpecFlow supported scenario outlines, Reqnroll’s native support for Cucumber Expressions can make parameterized steps more readable. You can use placeholders like {int}, {string}, {float} in step definitions, which improves clarity. For example, instead of a cryptic regex, [Then(“the order is [successfully ]processed”)] cleanly indicates an optional word successfully in the step. These small syntax improvements can make your test specifications more approachable to non-developers.
• Integration and Extensibility: Reqnroll has ported all major integration plugins that SpecFlow had. You can continue using dependency injection containers (Autofac, Microsoft DI, etc.) via Reqnroll.Autofac and others. The Visual Studio and Rider IDE integration is also in place, so you still get features like navigating from steps to definitions, etc. As Reqnroll evolves, expect even more integrations. Keep an eye on the official docs for new plugins (e.g., for report generation or other tools). The fact that Reqnroll is community-driven means that if you have a need, you can even write a plugin or extension for it.
• Parallel Execution and Async Support: Under the hood, Reqnroll generates task-based async code for your test execution, rather than the synchronous code SpecFlow used. This modernization can improve how tests run in parallel (especially in xUnit, which handles async tests differently) and positions the framework for better performance in the future. As a user, you don’t necessarily have to change anything to benefit from this, but it’s good to know that Reqnroll is using modern .NET async patterns which could yield speed improvements for I/O-bound test steps and such.

By exploring these features, you’ll get more value from your migration. Reqnroll is not just a stop-gap for SpecFlow; it’s an upgrade. Encourage your team to gradually incorporate these capabilities, for example, generate a periodic test report for the team, or start tagging scenarios with requirement IDs.

With the migration steps completed and new features in your toolkit, you’re all set on Reqnroll. Next, let’s compare SpecFlow and Reqnroll side-by-side and highlight what’s changed or improved.

SpecFlow vs Reqnroll – Key Differences and Benefits

To summarize the changes, here’s a comparison of SpecFlow and Reqnroll across important aspects:

As shown above, Reqnroll retains all the core capabilities of SpecFlow – so you’re not losing anything in the move – and it brings multiple benefits: active maintenance, new syntax options, performance alignments with async, and freedom from proprietary add-ons. In everyday use, you might barely notice a difference except when you upgrade to a new version of .NET or need a new plugin and find that Reqnroll already has you covered.

Conclusion: Embrace the Future of .NET BDD with Reqnroll

Migrating from SpecFlow to Reqnroll enables you to continue your BDD practices with confidence, knowing your framework is up-to-date and here to stay. The migration is straightforward, and the improvements are immediately tangible from smoother integration in modern toolchains to added features that enhance testing productivity. By following this step-by-step guide, you can smoothly transition your existing SpecFlow tests to Reqnroll and future-proof your test automation.

Now is the perfect time to make the switch and enjoy the robust capabilities Reqnroll offers. Don’t let your BDD framework become a legacy anchor; instead, embrace Reqnroll and keep rolling forward with behavior-driven development in your .NET projects.

Frequently Asked Questions