BddDotNet

BddDotNet is a behavior-driven development framework for C# and .NET that supports both Gherkin and code-authored scenarios. It suits .NET developers who want scenarios and execution to stay within a local project. Its flexible authoring and MIT license are compelling; the .NET 10+ requirement is the key adoption constraint.

Overview

BddDotNet gives teams two ways to express behavior: write Gherkin feature files or build scenarios in C# with a builder pattern. That accommodates readable, specification-style scenarios as well as cases where developers prefer to compose them in code. The framework runs locally through Microsoft.Testing.Platform, so it fits projects that want a local test backend rather than a separately hosted execution service.

Adoption means adding BddDotNet and its Gherkin source generator as NuGet packages in a .NET project. The setup guide walks through a console application created in Visual Studio or with the .NET CLI, and a GitHub wiki covers setup and features. The project is based on Microsoft.Extensions.* and describes public interfaces and dependency injection as extension points, giving teams room to integrate their own services.

Key features

• Gherkin source generation: A generator compiles feature files and registers their steps. This brings Gherkin scenarios into the .NET project’s build flow and makes the feature files useful as executable specifications.
• C# scenario builder: The builder pattern allows scenarios to be authored directly in C#. This is a practical alternative for developers who want to construct scenarios in code, though it may be less approachable to contributors who rely on Gherkin’s readable syntax.
• C# expressions in step arguments: Step arguments can use C# expressions, which gives developers more flexibility when expressing scenario inputs.
• Table transformations: Gherkin tables can be transformed into C# models, helping map structured scenario data into types used by the project.
• AOT and trimming support: The project describes itself as friendly to Native AOT deployment and trimming, a useful consideration for teams targeting those deployment styles.
• Separate feature packages: Additional features are distributed as separate NuGet packages. This modular approach lets projects add capabilities as needed, while requiring package setup for each chosen addition.

The main technical limit is runtime compatibility: BddDotNet supports .NET 10 and later. Projects that cannot move to that baseline should choose a framework compatible with their current runtime. The MIT license permits use, modification, distribution, and sublicensing under its terms, but provides the software without warranty.

Pricing

BddDotNet is free open-source software under the MIT License. The Open source plan costs nothing, with no free trial because there is no paid trial period to start. There are no seat or usage caps stated for this plan. The license allows teams to use and modify the software, subject to its terms; its no-warranty provision is relevant for organizations that need a vendor-backed commitment.

Platforms

BddDotNet supports Linux, macOS, and Windows. It is distributed through NuGet for .NET projects, with setup examples for Visual Studio and the .NET CLI. Platform support does not remove the .NET 10+ runtime requirement, so compatibility with the target project remains the deciding factor.

Who it's for

BddDotNet is a strong fit for C# teams adopting behavior-driven development who want Gherkin scenarios, C# scenario construction, and local execution in one .NET workflow. Its source generation, table-to-model transformations, and dependency-injection extension points serve teams that want to connect readable scenarios with typed application code. It is a poor fit for projects on older .NET runtimes or teams committed to a different testing backend.

Pros and cons

• Pro: Gherkin and C# builder authoring give teams a choice of scenario style within the same framework.
• Pro: Source generation compiles feature files and registers steps, tying Gherkin scenarios to the .NET project.
• Pro: The MIT license allows free use and modification, with no stated seat or usage caps.
• Pro: Public interfaces, dependency injection, and separate NuGet packages provide ways to extend the framework and add capabilities.
• Con: Support starts at .NET 10, excluding projects that need to remain on earlier runtimes.
• Con: Microsoft.Testing.Platform is the testing backend, which limits its appeal to teams that require another backend.
• Con: The MIT license comes without warranty, so teams needing a warranty commitment will need another arrangement.

Alternatives

For a different BDD framework, compare BDD Testing Tools. Serenity BDD is another free open-source option with Android, iOS, Linux, macOS, self-hosted, web, and Windows platforms; its JUnit 4 support is deprecated and planned for removal in Serenity 6.0.0. FitNesse is a free open-source project with Linux, macOS, self-hosted, web, Windows, and API platforms, with no commercial plans or limits stated. Choose Concordion if a Java library under the Apache License 2.0 better matches your stack.

Cucumber Open is a free open-source option for Android, API, Linux, macOS, and Windows, and Cucumber Reports are free. Ginkgo is a free Go testing framework for Linux, macOS, and Windows; its current supported major version is v2. CukeTest offers a free Lite plan with visual feature editing, JavaScript and Python, and 500 automation API calls, with usage limits on some built-in automation libraries. Karate offers a free MIT-licensed framework for REST, GraphQL, and SOAP API testing, browser and desktop UI automation, and Gatling performance testing. Reqnroll has a free Community plan with framework use, Visual Studio and Rider integration, community plugins, and community support.

Verdict

Choose BddDotNet if your C# project targets .NET 10 or later and you want Gherkin and C# scenario authoring with local execution under an MIT license. Its strongest reason to choose it is the combination of generated Gherkin steps and code-first scenarios in one .NET framework. Look elsewhere if your project uses an older runtime, needs a different testing backend, or requires a warranty commitment.