What should readiness communicate to an orchestrator?

Whether this instance should receive traffic now.

The favorite editor of the developer.

A teammate wants to hide WebApplicationFactory inside a convenient helper. What should you check first?

Whether the helper makes ownership, inputs, failures, and tests easier to review.

Whether it reduces the number of files regardless of behavior.

Whether it removes the need for the lesson checklist.

Whether it can skip the production signals for this course.

Which artifact best proves this .NET APIs lesson is ready for review?

A repeatable check tied to health check and OpenAPI response review.

A note that says the happy path was manually clicked once.

A screenshot with no command, test, or failure-mode context.

A broad refactor that avoids the specific lesson outcome.

Pro operations: a teammate says the happy path works, but "Integration tests and health signals" is still implicit. What should you ask for before merging?

A small contract, test, or review artifact that proves integration tests and health signals under a realistic failure case.

Skip compiler, OpenAPI, SQL, or host evidence until the capstone.

Hide the decision inside framework defaults so reviewers have less to read.

Treat production behavior as separate from the lesson implementation.

A reviewer has five minutes to evaluate this pro .NET APIs slice. Which evidence is strongest?

A focused artifact for deployment runbook and rollback signals plus a repeatable test, log, OpenAPI diff, or deployment check.

A passing build with no note about contracts, query shape, or operations.

A screenshot of Swagger without checking response or failure cases.

A broad rewrite that does not map to the stage milestone.

Learn / .NET API Engineering Path

Testing, Health, and Hosted Services

Add integration tests, health checks, structured logs, and a background worker that shuts down gracefully.

Course: .NET API Engineering Path. Level: Advanced. Topic: Typed backend.

Stage: pro - Pro operations - Production operations and reliability. Finish the path by proving the API behaves under real hosting concerns: tests, readiness, logging, background work, and shutdown.

Outcomes

Test endpoints with WebApplicationFactory.
Expose liveness and readiness checks.
Implement a cancellable hosted service.

Concepts

WebApplicationFactory
health check
ILogger
IHostedService

Concept flow

Show how production operations and reliability moves from trigger to implementation outcome in .NET APIs.

Test host
Endpoint
Service
DbContext
Health check
Hosted worker

Session flow

Model WebApplicationFactory (concept, 11 min) — Name the decisions behind WebApplicationFactory before writing code.
- Test endpoints with WebApplicationFactory.
- Explain where WebApplicationFactory belongs in order management API.
Build the vertical slice (walkthrough, 20 min) — Implement the smallest useful slice in Workers/ExpireOrdersWorker.cs.
- Expose liveness and readiness checks.
- Connect health check to a working example.
Verify and harden (exercise, 14 min) — Make a background loop observe cancellation.
- Implement a cancellable hosted service.
- Record one risk or follow-up before moving on.

Code example

C# in Workers/ExpireOrdersWorker.cs.

public sealed class ExpireOrdersWorker(IOrders orders, ILogger<ExpireOrdersWorker> logger) : BackgroundService
      {
          protected override async Task ExecuteAsync(CancellationToken stoppingToken)
          {
              while (!stoppingToken.IsCancellationRequested)
              {
                  await orders.ExpireStaleAsync(stoppingToken);
                  await Task.Delay(TimeSpan.FromMinutes(1), stoppingToken);
              }
          }
      }

Walkthrough examples

Testing, Health, and Hosted Services in a order management API — A team is extending a production-grade ASP.NET Core order API and needs this lesson's pattern to be clear enough for review, testing, and future maintenance.
- File: Workers/ExpireOrdersWorker.cs
- File: src/Orders.Application/testing-health-and-hosted-services.cs
- File: tests/Orders.Api.Tests/testing-health-and-hosted-services.Tests.cs
- File: docs/dotnet-advanced/testing-health-and-hosted-services.md
- Start from the provided C# snippet and make the intent visible in names and boundaries.
- Apply the checklist item "Test serialization through HTTP" before adding extra behavior.
- Write down how the implementation changes when health check fails or becomes slow.

Practice

Write one endpoint integration test.
Add a database readiness check.
Make a background loop observe cancellation.

Checklist

Test serialization through HTTP
Log structured fields
Separate liveness from readiness
Stop hosted services gracefully

Quiz prompts

What should readiness communicate to an orchestrator? — Readiness is a traffic-routing signal, often dependent on required services such as the database.
A teammate wants to hide WebApplicationFactory inside a convenient helper. What should you check first? — Place WebApplicationFactory at the boundary that keeps order management API behavior explicit, testable, and reviewable.
Which artifact best proves this .NET APIs lesson is ready for review? — Production-ready learning needs evidence: a test, trace, command, screenshot, or log that catches the risk again.
Pro operations: a teammate says the happy path works, but "Integration tests and health signals" is still implicit. What should you ask for before merging? — Integration tests and health signals belongs in the pro stage only when the decision is visible, testable, and tied to a realistic failure mode.
A reviewer has five minutes to evaluate this pro .NET APIs slice. Which evidence is strongest? — Complete the pro-grade host: integration tests, readiness/liveness split, structured logs, cancellable hosted worker, and a deployment note a teammate can run.

Flashcards

Pro operations: what decision does "Integration tests and health signals" force you to make? Use the real ASP.NET Core host boundary to verify serialization, dependencies, liveness, and readiness. Evidence prompt: Write one WebApplicationFactory test and document exactly what readiness checks.
Pro operations: what decision does "Hosted services and graceful shutdown" force you to make? Make background work observable, cancellable, and safe during deploys. Evidence prompt: Add a cancellation test or manual proof for the hosted worker loop.
Pro operations: what decision does "Deployment runbook and rollback signals" force you to make? Define the health, log, and metric signals that decide whether a deployment continues or rolls back. Evidence prompt: Write a two-minute deploy runbook with the exact readiness, log, and rollback checks a teammate should run.
In .NET APIs, what should you remember about WebApplicationFactory? WebApplicationFactory matters here because it supports "Test endpoints with WebApplicationFactory.".
In .NET APIs, what should you remember about health check? health check matters here because it supports "Expose liveness and readiness checks.".
In .NET APIs, what should you remember about ILogger? ILogger matters here because it supports "Implement a cancellable hosted service.".
In .NET APIs, what should you remember about IHostedService? IHostedService matters here because it supports "Test endpoints with WebApplicationFactory.".

Labs

Ship a testing, health, and hosted services slice — Extend a production-grade ASP.NET Core order API with a small but reviewable feature that proves the lesson's architecture in code.
- Complete the pro-grade host: integration tests, readiness/liveness split, structured logs, cancellable hosted worker, and a deployment note a teammate can run.
- Write one WebApplicationFactory test and document exactly what readiness checks.
- Add a cancellation test or manual proof for the hosted worker loop.
- Write a two-minute deploy runbook with the exact readiness, log, and rollback checks a teammate should run.
- Write one endpoint integration test.
- Add a database readiness check.
- The lab demonstrates the pro operations outcome without skipping earlier contract evidence.
- Each subtopic has a concrete artifact: Integration tests and health signals, Hosted services and graceful shutdown, Deployment runbook and rollback signals.
- The review notes explain how this level changes ownership, verification, or operational risk.

Challenge

Review-ready testing, health, and hosted services (Core) — Complete the pro-grade host: integration tests, readiness/liveness split, structured logs, cancellable hosted worker, and a deployment note a teammate can run.
- All checklist items are either implemented or documented with a reason.
- The change can be understood from Workers/ExpireOrdersWorker.cs plus one short note.
- The concept diagram names ownership, failure handling, and verification points.
- A teammate could run the verification steps without asking for hidden context.

Canonical lesson URL