# ProtoTest > ProtoTest is an integration testing foundation for .NET 8, 9 and 10. A suite composes its applications, data and clients once; every test gets its own context and owned cleanup, and the run writes a .prototrace archive. A read-only MCP server and the prototest CLI hand that evidence to coding agents. ## Reference - [.NET integration testing with ProtoTest](https://prototest.dev/docs): Start with the path that matches what you bring: learn integration testing, evaluate ProtoTest, or find your way around an existing suite. ## Reference / Getting started - [Install ProtoTest](https://prototest.dev/docs/getting-started/installation): Install ProtoTest from the template, or add the runner and integration packages to a test project of your own. - [Write your first .NET integration test](https://prototest.dev/docs/getting-started/first-test): Build a small ProtoTest suite against an ASP.NET Core API, run it, make it fail once, and read the trace. - [Configure ProtoTest](https://prototest.dev/docs/getting-started/configuration): Set ProtoTest options in code, in configuration, or both, so one suite runs in-process on a laptop and against a deployed environment in CI. - [Run one suite in three environments](https://prototest.dev/docs/getting-started/environments): Run the same suite in-process, container-backed or against a published environment, changing only the host's setup and configuration. - [Troubleshoot ProtoTest](https://prototest.dev/docs/getting-started/troubleshooting): The first problems a new suite runs into, and what fixes them: the host, the context, clients, containers, browsers, parallel tests and missing artifacts. - [Migrating from 1.0 to 1.1](https://prototest.dev/docs/getting-started/migrating-from-1-0): What a 1.0 suite changes for 1.1: the renamed package and options section, and the surface that keeps working but is deprecated. ## Reference / Foundation - [ProtoTest foundation](https://prototest.dev/docs/foundation/overview): The handful of ProtoTest.Core concepts every integration builds on: the host, the execution context, attributes, clients, hooks and the trace. - [Vocabulary](https://prototest.dev/docs/foundation/vocabulary): Every ProtoTest word the docs and the lessons use, in one plain sentence, with the lesson that teaches it and the page with the details. - [Execution context](https://prototest.dev/docs/foundation/execution-context): ProtoExecutionContext lives for exactly one test and holds its clients, state, services, resources, attachments and observations. - [Execution context advanced topics](https://prototest.dev/docs/foundation/execution-context-advanced): The execution context pieces a suite reaches for less often: services, resources, findings, observations and the trace writer. - [Host and lifecycle](https://prototest.dev/docs/foundation/lifecycle): How the ProtoTest host is built, started and stopped, and the order in which a test's hooks, attributes and clients run. - [Host API](https://prototest.dev/docs/foundation/lifecycle-host-api): The ProtoHost surface for runner integrations: starting and completing tests by hand, and the host members. - [Attributes](https://prototest.dev/docs/foundation/attributes): Turn setup into a named, reusable capability with a ProtoTest attribute, and compose it onto any test that needs it. - [Clients](https://prototest.dev/docs/foundation/clients): Clients are what a test talks to. ProtoTest creates them per test, registers them on the context and disposes them afterwards. - [Assertions](https://prototest.dev/docs/foundation/assertions): One assertion surface across every integration: Should and ShouldNot, chainable members, and shape matching as the chain continuation. - [Shape matching](https://prototest.dev/docs/foundation/shape-matching): Describe the JSON you expect with an anonymous object: partial, nested, with value constraints, and every mismatch reported at once with its path. - [Hooks](https://prototest.dev/docs/foundation/hooks): Run code around every test or around the whole run without touching a test: correlation ids, shared resets, one-off startup. - [Attachments](https://prototest.dev/docs/foundation/attachments): Files a test produces reach your runner, so they show up next to the result in your IDE or CI, and land in the trace. - [Skip conditions](https://prototest.dev/docs/foundation/skip-conditions): Skip a test before its lifecycle starts, with a reason, when the environment cannot run it, so it reads as skipped instead of failed. - [Infrastructure](https://prototest.dev/docs/foundation/infrastructure): Declare a database, broker or emulator on the host; it starts once before any test, fills configuration, and is released with the run. - [Infrastructure recipes](https://prototest.dev/docs/foundation/infrastructure-recipes): Infrastructure recipes: the sample flows, readiness probes, run-scoped setup, and AddResource against AddInfrastructure. - [Control time in tests with TimeProvider](https://prototest.dev/docs/foundation/time): Advance a clock instead of sleeping: each test gets its own TimeProvider, the in-process application sees it, and every advance is recorded in the trace. - [Environment resolution](https://prototest.dev/docs/foundation/environment-resolution): Declare what the run needs as a target with an ordered provider chain: the first provider whose condition holds serves it, and the trace records the decision. - [Run .NET integration tests in parallel safely](https://prototest.dev/docs/foundation/concurrency): How ProtoTest keeps parallel tests isolated, what to do when a test fans out internally, and the parallelism the project has actually exercised. ## Reference / Integrations - [What ProtoTest can test: the integrations](https://prototest.dev/docs/integrations/overview): Every ProtoTest integration on one page: protocols, browsers, messaging, devices, data and files, applications, runners and the tooling around the run. - [Check API coverage against your OpenAPI spec](https://prototest.dev/docs/integrations/openapi): Compare what your REST tests did against your OpenAPI document, and find the endpoints, responses and properties no test has checked. - [Test ASP.NET Core apps in-process](https://prototest.dev/docs/integrations/aspnetcore): Run your ASP.NET Core application in-process with WebApplicationFactory and hand its HttpClient to REST and GraphQL: no deployment, no ports. - [Fake HTTP dependencies with WireMock.Net](https://prototest.dev/docs/integrations/wiremock): Stub an HTTP dependency per test with WireMock.Net: scenario-like stubs, REST-shaped trace evidence and stub coverage. - [Test an Aspire AppHost from your test suite](https://prototest.dev/docs/integrations/aspire): Run an Aspire AppHost with the suite: the run starts it, each resource becomes an application target, and the run releases it. - [Test .NET background workers and hosted services](https://prototest.dev/docs/integrations/hosting): Run a background worker or generic host in-process with the suite: it starts with the run, reads the run's settings and stops with the run. - [Test devices over WebSocket, MQTT, TCP or serial](https://prototest.dev/docs/integrations/devices): Talk to devices over WebSocket, MQTT, TCP or a serial port, build their data strings as typed messages, and keep every exchange in the trace. ## Reference / Integrations / Web - [Browser tests with Playwright or Selenium in .NET](https://prototest.dev/docs/integrations/web): A driver-independent browser-testing model for pages, components, flows and login, run by Playwright or Selenium underneath. - [Page coverage](https://prototest.dev/docs/integrations/web/page-coverage): Which pages a browser suite visited and verified, and where the inventory comes from. - [Pages and components](https://prototest.dev/docs/integrations/web/page-objects): Model a browser UI with pages, components, elements and tables, so tests read as what a user does rather than as markup. - [Locators](https://prototest.dev/docs/integrations/web/locators): Find elements by role, label and text rather than CSS; each backend translates a WebLocator into its native query. - [Actions and assertions](https://prototest.dev/docs/integrations/web/interactions): Click, type, select and assert on a WebElement; every action waits until the element is ready to take it. - [Flows](https://prototest.dev/docs/integrations/web/flows): Group steps on one component into a named flow that reads as one operation in the trace, with its steps nested beneath. - [Logging in](https://prototest.dev/docs/integrations/web/login): Log in once per test the way your application does: through its login page or as a user another attribute provisioned, as a reusable capability. - [Waits and middleware](https://prototest.dev/docs/integrations/web/middleware): Register your application's notion of ready, such as spinners, in-flight requests or animations, once instead of sleeping in tests. - [Diagnostics and artifacts](https://prototest.dev/docs/integrations/web/diagnostics): Screenshots, console output, page errors, failed requests and Playwright traces are captured automatically and attached to the failing test. ## Reference / Integrations / REST - [Test REST APIs in .NET](https://prototest.dev/docs/integrations/rest): A per-test HTTP client on IHttpClientFactory, with JSON shape assertions, shared authentication, capture and coverage. - [Building requests](https://prototest.dev/docs/integrations/rest/requests): Build a REST request fluently with route parameters, body, headers and authentication, and send it with a verb method. - [Responses and assertions](https://prototest.dev/docs/integrations/rest/responses): Assert on a RestResponse: status, headers, JSON shapes and typed bodies, with the body buffered so it can be read any number of times. - [Authentication](https://prototest.dev/docs/integrations/rest/authentication): One authentication model for REST, GraphQL and gRPC: an authenticator adds what the API needs just before each request is sent. - [Attachments and coverage](https://prototest.dev/docs/integrations/rest/attachments): Capture REST requests and responses as attachments, and record which endpoints and properties your suite asserted. ## Reference / Integrations / GraphQL - [Test GraphQL APIs in .NET](https://prototest.dev/docs/integrations/graphql): A per-test GraphQL client for queries, mutations and subscriptions over WebSocket or SSE, with uploads, shape assertions and schema coverage. - [Queries and mutations](https://prototest.dev/docs/integrations/graphql/operations): Three ways to describe a GraphQL query or mutation: shape-driven, fluent or a raw document, all ending in the same ExecuteAsync(). - [Responses](https://prototest.dev/docs/integrations/graphql/responses): Assert on GraphQL responses: data shapes and errors, with the same shape matcher REST uses. - [Subscriptions](https://prototest.dev/docs/integrations/graphql/subscriptions): Test GraphQL subscriptions over WebSocket (graphql-transport-ws) or Server-Sent Events, awaiting the next result with a shape and a timeout. - [Schema coverage](https://prototest.dev/docs/integrations/graphql/coverage): Point ProtoTest at your GraphQL schema to see which types, fields, arguments and input fields your suite exercised. - [Your first GraphQL suite](https://prototest.dev/docs/integrations/graphql/first-suite): From a fresh test project to a passing query, a mutation whose result is asserted, and a subscription that waits for an event. ## Reference / Integrations / Data - [Create test data per test in .NET](https://prototest.dev/docs/integrations/data): Build test objects with deterministic defaults, so a test only states the values it is about, and create them in the system under test. - [Defaults](https://prototest.dev/docs/integrations/data/defaults): Keep test-data defaults in small modules, one per feature area, next to the tests that use them. - [Provisioners](https://prototest.dev/docs/integrations/data/provisioners): A provisioner creates a built object in the system under test, returns what the system gave back, and cleans it up afterwards. ## Reference / Integrations / gRPC - [Test gRPC services in .NET](https://prototest.dev/docs/integrations/grpc): A named gRPC client per test for unary and streaming calls, with metadata authentication, shape and status assertions, per-call tracing and method coverage. - [Calls and assertions](https://prototest.dev/docs/integrations/grpc/calls): Call a gRPC service with the traced unary and streaming helpers, keep the method descriptors in one holder, and assert on the reply or the status. ## Reference / Integrations / Messaging - [Test RabbitMQ and message events in .NET](https://prototest.dev/docs/integrations/messaging): Publish a message, then await the one that matters with a predicate and a timeout, on RabbitMQ or your own broker adapter. - [MassTransit bridge](https://prototest.dev/docs/integrations/messaging/masstransit): Bridge the messaging surface to the application's in-process MassTransit test harness: publish commands and await the events the application publishes. - [Adapter contract](https://prototest.dev/docs/integrations/messaging/adapters): How a broker adapter plugs into the messaging surface: the broker, the per-test consumer, and the await base. ## Reference / Integrations / Sheets - [Test Excel workbook downloads in .NET](https://prototest.dev/docs/integrations/sheets): Open the .xlsx your application generated and assert on its sheets, cells, ranges and typed rows. ## Reference / Integrations / SQL - [Check the database in .NET integration tests](https://prototest.dev/docs/integrations/sql): A database connection each test owns, optionally wrapped in a transaction that is rolled back at the end, with Entity Framework Core on top. ## Reference / Recipes - [Integration testing recipes](https://prototest.dev/docs/recipes/overview): Scenarios that combine ProtoTest capabilities in one test: an API call and its event, a write and its row, an API and a browser. - [An API call publishes an event](https://prototest.dev/docs/recipes/api-publishes-an-event): Pay an invoice over REST, then await the invoice.paid event the application publishes, with the broker started and owned by the run. - [A write lands in the database](https://prototest.dev/docs/recipes/write-lands-in-the-database): Create a project over REST, then read the committed row through the suite's own connection to the store the application writes to. - [Created through the API, shown in the browser](https://prototest.dev/docs/recipes/api-then-browser): Arrange a project through the API, sign a real browser in, and check that the projects page renders it. - [A downloaded report matches its model](https://prototest.dev/docs/recipes/download-a-report): Download the workbook the application generates over REST and verify it with a typed sheet model: layout, column rules and the row the test created. - [Written over REST, read over GraphQL](https://prototest.dev/docs/recipes/rest-then-graphql): Create a project over REST and read it back through the GraphQL API of the same application, both clients on one in-process server. ## Reference / Observability - [ProtoTrace: see what an integration test did](https://prototest.dev/docs/observability/prototrace): One portable .prototrace file records every hook, client, request, check and state change of a run, ready for the browser viewer. - [The .prototrace archive](https://prototest.dev/docs/observability/prototrace-archive): What the .prototrace file holds: the ZIP layout, the spans and state documents, format compatibility, run metadata and lifetime. - [Coverage and observations](https://prototest.dev/docs/observability/coverage): Coverage of your API's surface rather than its lines: which endpoints, responses, fields and methods your suite actually asserted. - [Reporting](https://prototest.dev/docs/observability/reporting): Write collected observations and coverage out once per run, as JSON or as a self-contained HTML report. - [OpenTelemetry](https://prototest.dev/docs/observability/opentelemetry): Export ProtoTest operations to OpenTelemetry, so test runs land in the same tracing backend as your application. - [Where your evidence goes](https://prototest.dev/docs/observability/where-evidence-goes): One run writes one .prototrace archive for five readers: the viewer, report sinks, OpenTelemetry, the prototest CLI and the MCP server. ## Reference / Test runners - [.NET test runners](https://prototest.dev/docs/runners/overview): ProtoTest plugs into the runner you already use: NUnit, xUnit v2 and v3, MSTest or TUnit, with one host, one context and one trace behind each. - [xUnit v2](https://prototest.dev/docs/runners/xunit): Register ProtoTest with xUnit v2: the collection fixture, [ProtoTestFact] and [ProtoTestTheory], what the adapter changes and its limits. - [xUnit v3](https://prototest.dev/docs/runners/xunit3): Register ProtoTest with xUnit v3: the assembly fixture, [ProtoTestFact] and [ProtoTestTheory], what the adapter changes and its limits. - [NUnit](https://prototest.dev/docs/runners/nunit): Register ProtoTest with NUnit: the SetUpFixture, the [ProtoTest] attribute, what the adapter changes and its limits. - [MSTest](https://prototest.dev/docs/runners/mstest): Register ProtoTest with MSTest: the assembly hooks, the [ProtoTest] attribute, what the adapter changes and its limits. - [TUnit](https://prototest.dev/docs/runners/tunit): Register ProtoTest with TUnit: the test executor, the assembly hooks, TUnit's own [Test] attribute, what the adapter changes and its limits. - [Bring an existing suite](https://prototest.dev/docs/runners/bring-your-existing-suite): Move an existing suite onto ProtoTest test by test: what keeps running, what converts, and the order that stays green for xUnit, NUnit, MSTest and TUnit. ## Reference / Continuous integration - [Continuous integration](https://prototest.dev/docs/continuous-integration): Run ProtoTest in CI and keep the trace, reports and runner output together as build artifacts on GitHub Actions, Azure Pipelines or GitLab CI. - [Azure Pipelines](https://prototest.dev/docs/continuous-integration/azure-pipelines): Run ProtoTest on Azure Pipelines and publish the trace, reports and runner output as a pipeline artifact. - [GitLab CI](https://prototest.dev/docs/continuous-integration/gitlab-ci): Run ProtoTest on GitLab CI and keep the trace, reports and runner output as job artifacts. ## Reference / Extending - [Extending ProtoTest](https://prototest.dev/docs/advanced/extending): The public extension points behind every built-in integration, and the contract a package of your own follows. - [Design system](https://prototest.dev/docs/advanced/design-system): The one visual language ProtoTrace, the HTML report and these docs share, and how to use it in your own sinks and entry kinds. ## Reference / Agent workflows - [Coding agents](https://prototest.dev/docs/agent-workflows/coding-agents): The workflow a coding agent follows over ProtoTest evidence, the tools it calls, and what stays on your machine. - [Set up a coding agent with ProtoTest](https://prototest.dev/docs/agent-workflows/setup): Install the ProtoTest MCP server and register it with a coding agent so it can read the runs in your repository. - [Diagnosis](https://prototest.dev/docs/agent-workflows/diagnosis): The deterministic document that says which test failed, why, and what the failing operation carried, for a terminal or a coding agent. - [Verification](https://prototest.dev/docs/agent-workflows/verification): Compare two runs' reports and return the pull request verdict: coverage regressions, new uncovered units, specification identity and failed run gates. - [The evidence loop](https://prototest.dev/docs/agent-workflows/loop): The evidence loop end to end: fail, evidence, fix, verify, report, with the pull request comment and the check annotations each step produces. - [CLI reference](https://prototest.dev/docs/agent-workflows/cli): The prototest CLI: the seven verbs, their arguments, the environment targets and the exit codes. ## Reference / Project - [Why I built ProtoTest](https://prototest.dev/docs/project/why-prototest): The problems in .NET integration testing, and the earlier experience, that led to building ProtoTest. - [ProtoTest vs Testcontainers, Alba and Aspire testing](https://prototest.dev/docs/project/compare): An honest comparison: where ProtoTest wins against the alternatives, where each alternative wins, and when ProtoTest is not the right choice. - [Benchmarks](https://prototest.dev/docs/project/benchmarks): Measured trace size, run time, export time and memory growth for synthetic suites, and the levers that change them. - [Roadmap](https://prototest.dev/docs/project/roadmap): What is committed next in ProtoTest, what is being explored, and what is deliberately not planned - with the reasoning behind each. - [Frequently asked questions](https://prototest.dev/docs/project/faq): Short answers to the questions evaluators ask about ProtoTest: wrappers, runners, coverage, licensing, telemetry and AI usage. - [Support and sustainability](https://prototest.dev/docs/project/sustainability): Who maintains ProtoTest, how it is funded, what the versioning and deprecation policy is, and what happens if the maintainer stops. - [AI usage](https://prototest.dev/docs/project/ai-usage): How and why AI was used while building ProtoTest, and how its output was checked before it shipped. - [Analyzers](https://prototest.dev/docs/project/analyzers): ProtoTest.Analyzers warns about what the framework cannot catch at runtime and the shortcuts a test should not take. - [Leaving ProtoTest](https://prototest.dev/docs/project/leaving): How to unadopt ProtoTest: remove the host, swap the attributes and assertions back, and keep the traces and reports. ## Learn - [Learn integration testing](https://prototest.dev/learn): Hands-on lessons for .NET integration testing: write your first test, test real boundaries, make tests reliable, read failures. - [Why integration tests get hard](https://prototest.dev/learn/why-it-gets-hard): The failures every team recognizes, the four causes behind them, and the track that teaches each fix. ## Learn / Start - [Run the sample suite](https://prototest.dev/learn/start/install-and-run): Run the Northstar.ProtoTest sample suite with one command, find the trace it leaves, and read why some tests skip. - [Write your first .NET API integration test with ProtoTest](https://prototest.dev/learn/start/write-your-first-test): Add a C# API integration test to the prepared ProtoTest sample, give it isolated data, check the response, and run it with dotnet test. - [See why a test failed](https://prototest.dev/learn/start/read-the-trace): Break your first test on purpose, open its trace in the viewer, and find the failing check, the values that differed and the line of code. ## Learn / Write good integration tests - [Read what your run provides](https://prototest.dev/learn/good-tests/capabilities-and-the-host): Read a run's capability list in the trace, find the line in Setup.cs that declared each one, and tell what the host owns from what a test owns. - [Know when the host starts and stops](https://prototest.dev/learn/good-tests/one-host-one-lifetime): See what the setup class does before the first test and after the last, and why the builder refuses registrations once the host is built. - [Add and remove an integration](https://prototest.dev/learn/good-tests/add-and-remove-an-integration): Watch a test skip because the run lacks a capability, add the broker that serves it, and remove it again without touching the test. - [Sign in as a test user](https://prototest.dev/learn/good-tests/sign-in-as-a-test-user): Declare the user a test acts as with [SignedInAs], read the identity in the trace, and see what the test user cannot do against a published app. - [Give each test its own state](https://prototest.dev/learn/good-tests/per-test-state-and-cleanup): Provision the data a test reads under a name built from its test id, and read only what the test created. - [Check that a test cleans up](https://prototest.dev/learn/good-tests/what-a-test-leaves-behind): Read cleanup and resource-release evidence in a passing trace, and investigate missing or failed cleanup. - [Decide what belongs in the host](https://prototest.dev/learn/good-tests/when-not-to-compose): Decide whether a piece belongs to the host, to a test, or to neither, and recognize the three common ways suites get it wrong. ## Learn / Across boundaries - [Call an API and check its shape](https://prototest.dev/learn/across-boundaries/call-an-api): Send one REST request from a test and check the status and the shape of the response. - [Write over REST, read over GraphQL](https://prototest.dev/learn/across-boundaries/query-graphql): Create data through REST and read it back through GraphQL in one test. - [Check what the application stored](https://prototest.dev/learn/across-boundaries/check-the-database): Create data through the API, then read the row from the database to prove it was committed. - [Drive the browser with a page object](https://prototest.dev/learn/across-boundaries/drive-the-browser): Describe a page once as a class, then sign in and read a project row in a real browser. - [Follow a message through a broker](https://prototest.dev/learn/across-boundaries/follow-a-message): Trigger an event through the API and await the message the application publishes. - [Check a generated file](https://prototest.dev/learn/across-boundaries/workbook-as-attachment): Download a workbook the application generated, check it through a record model and find it in the trace. ## Learn / Reliable tests - [Move the test clock](https://prototest.dev/learn/reliable-tests/the-test-clock): Replace a test that waits on real time with one that moves the clock, and read the clock event in the trace. - [Replace sleeps with readiness checks in .NET integration tests](https://prototest.dev/learn/reliable-tests/readiness-instead-of-sleeps): Replace fixed sleeps in .NET integration tests with an HTTP readiness probe, and inspect each wait in a ProtoTest trace. - [Run .NET integration tests in parallel safely](https://prototest.dev/learn/reliable-tests/parallel-safety): Find shared state that breaks .NET integration tests in parallel, then isolate test data with per-test tenants and owned cleanup. - [Wait for a read that lags a write](https://prototest.dev/learn/reliable-tests/wait-for-a-lagging-read): Poll a read with a deadline when background work updates it, and count the probes in the trace. ## Learn / Understand failures - [Run four failures on purpose](https://prototest.dev/learn/understand-failures/a-failure-tour): Run the four deliberate failures in the Northstar sample suite and see what each one is missing, next to the test that does the same journey right. - [Read a failing trace](https://prototest.dev/learn/understand-failures/read-a-failing-trace): Open one failing trace in the viewer, name the check that failed and the call it judged, and let the paired test name the fix. - [Fix a failure with one change per run](https://prototest.dev/learn/understand-failures/the-trace-as-the-feedback-loop): Use the trace to turn a failed run into one change, rerun, and compare the two traces. - [Diagnose flaky .NET integration tests with run traces](https://prototest.dev/learn/understand-failures/diagnose-a-flaky-test): Compare passing and failing .NET integration test traces, find the first differing value, and reproduce a timing failure before fixing it. - [Why a passing test can still leave an error](https://prototest.dev/learn/understand-failures/findings): Break a teardown on purpose and follow it into the report as a finding, which explains an outcome without replacing the test result. - [Why the run is red when every test is green](https://prototest.dev/learn/understand-failures/run-gates): Read the run gate that turns an Error finding into a failed run while the test list stays green. - [What did my suite never check?](https://prototest.dev/learn/understand-failures/contract-coverage): Read what a run checked about your API's contract, endpoints, statuses and fields, next to what it only saw. - [What is inside the file CI uploads?](https://prototest.dev/learn/understand-failures/artifacts-and-reports): Open a .prototrace in the viewer and with an archive tool, and find the operations and the JSON and HTML reports inside it. - [Keep the evidence when CI fails](https://prototest.dev/learn/understand-failures/evidence-in-ci): Put the trace and the reports in one directory, upload it even when the test step fails, and post the digest with the action. ## Learn / Real systems - [Run the suite on containers](https://prototest.dev/learn/real-systems/containers): Run the OpenCSMS suite with a PostgreSQL and a RabbitMQ container the run owns, and read the counts the run reported. - [Let Aspire start the topology](https://prototest.dev/learn/real-systems/aspire-topology): Select the OpenCSMS AppHost with one key and let it run the API and both workers as real processes beside fresh containers. - [Point the suite at a real stack](https://prototest.dev/learn/real-systems/published-mode): Run the OpenCSMS API and both workers as real processes, hand the suite their addresses, and read what it skips. - [Inject faults on purpose](https://prototest.dev/learn/real-systems/fault-injection): Replace a service for one test, follow failed notification deliveries into a dead-letter queue, and read a recorded billing regression. ## Learn / Extend ProtoTest - [Write your own attribute](https://prototest.dev/learn/extend/attributes): Turn repeated test setup into a named attribute, group attributes into one, and find their before and after entries in the trace. - [Create test data with a provisioner](https://prototest.dev/learn/extend/provisioners): Create test data through a provisioner, register it once, and read its chain in the trace. - [Model a screen as a page object](https://prototest.dev/learn/extend/page-objects): Describe a screen as a page object, write a browser journey against it, and find its component paths in the trace. - [Write an integration](https://prototest.dev/learn/extend/write-an-integration): Add your own client, hook and trace entries so a system ProtoTest does not know behaves like a built-in one. - [Swap a dependency for one test](https://prototest.dev/learn/extend/swap-a-dependency-for-one-test): Replace one service in the application under test for a single test, read the dedicated server in the trace, and see when the framework refuses. - [Run the evidence loop with an agent](https://prototest.dev/learn/extend/evidence-loop-with-an-agent): Summarize a failing trace with the CLI, connect a coding agent to the same file over MCP, and let ProtoTest judge the fix.