Precept

A .NET 10 test automation framework with its own test runner and the modules an end-to-end suite needs.

Precept implements ITestFramework on Microsoft.Testing.Platform, so it owns discovery, scheduling, retries, lifecycle and reporting — while still working with dotnet test, dotnet run, IDE test explorers and TRX reporting. On that runner it ships what an end-to-end suite otherwise assembles by hand: HTTP, browsers, databases, gRPC, containers, test data, per-environment configuration, and reporting to ReportPortal, Teams and Azure DevOps.

A test is a C# class with attributes. Gherkin is one way to write one rather than the price of entry: add Precept.Reqnroll and feature files are compiled by Reqnroll through a custom generator plugin into the same attributed classes.

C# classes with [TestSuite] / [Test]      .feature files  ── optional, via Precept.Reqnroll
                    │                            │  Reqnroll parser + Precept.Reqnroll.Generator
                    │                            │  emit the same attributed classes
                    └──────────────┬─────────────┘
                                   │  Precept.TestPlatform  (ITestFramework)
                                   ▼
          Microsoft.Testing.Platform → dotnet test / IDE / TRX

Start here#

What a test looks like#

[TestSuite("Checkout")]
[TestCategory("smoke")]
public class CheckoutTests
{
    [Test("A customer can check out")]
    [Retry(2, DelayMilliseconds = 200)]
    public async Task Checkout()
    {
        var response = await Rest.Post("/orders")
            .WithJsonBody(new { sku = "ABC", quantity = 2 })
            .SendAsync();

        await Assert.That(response).ToHaveStatusAsync(HttpStatusCode.Created);
        await Assert.That(response).ToHaveJsonValueAsync("status", "created");
    }
}

With Precept.Reqnroll referenced, the same suite written in Gherkin compiles to the same thing, and lands in the test explorer at the Scenario: line of the .feature file rather than in generated code — see writing tests and test explorer navigation.

What comes with it#

Module	What it adds
`Precept.Reqnroll`	Gherkin: `.feature` files compiled into Precept test classes.
`Precept.Api`	A fluent HTTP client and response assertions, logged into the test's report.
`Precept.Web`	Playwright, isolated per scenario, capturing screenshots, traces and video on failure.
`Precept.Screenplay`	The screenplay pattern over those modules: actors, abilities, interactions and questions.
`Precept.Data`	Provider-agnostic ADO.NET for seeding and asserting against a database.
`Precept.TestData`	Environment-specific data sets, generated values, factories, and pooled records.
`Precept.Files`	Excel, CSV, JSON and XML files written from a data table, read back as rows, and asserted on.
`Precept.Grpc`	Pooled channels, typed clients, and assertions over status codes and streaming.
`Precept.Containers`	Docker dependencies for a run, overridable by configuration.
Reporting	ReportPortal, Teams and Azure DevOps test cases, off the test's thread.

Every module depends only on Precept.Core and is registered from one startup class; nothing is on unless a suite asks for it. Two are shaped differently: Precept.Reqnroll adds MSBuild targets rather than services, and Precept.Screenplay sits on top of the other modules rather than beside them — both are ways of writing a suite rather than things to register.

How a run is put together#

Configuration — precept.json, overlays, and settings of your own.
Environments — how one is chosen, and how to switch from an IDE without editing a file.
Execution model — what runs in parallel, and why a high MaxParallelism can look ignored.
Filtering — selecting a subset, and removing tests from an environment entirely.
Artifacts and logging — what reaches a TRX, a test explorer and a report.
Running a suite on CI — a complete Azure Pipelines example.