Precept.TestData

Test data management for Precept: environment-specific data sets for the users, clients, vehicles and anything else a suite needs, dynamic value generation, factories that create and clean up data in the system under test, and pooled records leased exclusively to parallel tests.

dotnet add package Precept.TestData

services.AddPreceptTestData();

// testdata.json, beside the test binary
{
  "users": {
    "admin": { "username": "admin@acme.test", "password": "{{env:ADMIN_PASSWORD}}" }
  },
  "clients": {
    "new": { "name": "Acme {{unique}}", "email": "acme-{{unique}}@acme.test" }
  }
}

var admin = TestData.Get<TestUser>("admin");
var password = TestData.Value("users:admin:password");

testdata.json is overlaid by testdata.{environment}.json and then by PRECEPT_TESTDATA__* environment variables — which is how a password reaches a run without being written down in the repository.

{{unique}}, {{guid}}, {{now:+2d}}, {{random:1000-9999}} and friends are expanded when a value is read, so a suite that inserts the same email address on every run stops failing on the second one. Within a scenario the values are stable, so every step sees what the first one created; a retry generates fresh ones, so a test that failed on a duplicate key stops colliding with itself.

The module's types live in the root Precept namespace, so a step definition needs no further using.

A coding agent can get all of this — checked against the project in front of it, down to which set a type reads and whether the data files reach the output directory — from precept_explain_testdata in Precept.Mcp.

Part of Precept, a .NET 10 test automation framework. Full documentation: test data · dynamic values · factories · pooled data