Mokkit gives your tests the readability of BDD tools like Cucumber/SpecFlow, but with no DSL: no feature files, no step bindings, no runtime glue. The "steps" are just C# extension methods you author — your project's testing vocabulary — so you keep full IDE support (autocomplete, go-to-definition, refactoring) and a test that doesn't make sense simply won't compile.

It's a thin orchestration layer, not a framework: run it inside xUnit / NUnit / MSTest / TUnit, mock with Moq / NSubstitute / FakeItEasy, and wire with Microsoft DI / Autofac / Castle Windsor (or the dependency-free Bag). The same Arrange / Act / Inspect vocabulary scales from a mocked unit test to a full Testcontainers end-to-end run.

// A Mokkit test reads like the scenario it describes.
[Fact]
public async Task Suspending_a_client_reflects_everywhere()
{
    await Arrange
        .NewClient(out var clientId, WithName("Acme Corporation"))
        .CacheHasClient(clientId);

    await Act(clientId, ClientStatus.Suspended);

    await Inspect
        .ApiClientEventually(clientId, c => c.Status == Suspended)
        .DbClient(clientId, c => c!.Status.ShouldBe(Suspended))
        .EventPublished("clients.updated", clientId);
}

NewClient, CacheHasClient, ApiClientEventually, DbClient, EventPublished aren't Mokkit APIs — they're your verbs. Mokkit provides the Arrange / Act / Inspect shape and the machinery underneath.

Core + a DI adapter + a mock adapter (prerelease for now):

dotnet add package Mokkit --prerelease
dotnet add package Mokkit.Containers.Microsoft.Extensions.DependencyInjection --prerelease
dotnet add package Mokkit.Containers.NSubstitute --prerelease

Full guides, concepts and API reference: mokkit.net

• Introduction · Why Mokkit? (vs BDD/DSL) · Quickstart
• Building your test vocabulary — the idea Mokkit is built around

A worked, three-tier example (unit / integration / e2e) lives in example/Example1.

MIT © Nikita Ivanov