ASP.NET Core Integration Testing

WebApplicationFactory boots the application with a test host and produces HttpClient instances that traverse the ASP.NET Core pipeline. This catches composition failures that isolated handler tests cannot see.

Advanced C# work improves when you separate language syntax, runtime behavior, and application policy. Write down which layer owns the guarantee in this lesson. Then identify the observable evidence—a compiler rejection, test result, generated query, trace, or measurement—that would prove the model correct.

Override registrations for a disposable database, fake clock, or stub outbound HTTP handler. Seed data per test, use unique identifiers, and reset state deterministically. Authentication test schemes can produce controlled claims without weakening production configuration.

The starter isolates one part of the mental model so it can run in the browser. The exercise moves the same rule into a current local .NET project where packages, framework hosting, diagnostics, and multi-file tests are available.

using System;

class Response
{
  public int Status { get; private set; }
  public Response(int status) { Status = status; }
}
class Program
{
  static void AssertStatus(int expected, Response actual)
  {
      if (actual.Status != expected) throw new Exception("Unexpected status.");
  }
  static void Main() { AssertStatus(201, new Response(201)); Console.WriteLine("passed"); }
}

passed

Mocking the endpoint handler bypasses the feature being tested. A shared mutable database creates order-dependent failures. In-memory providers may differ materially from the production database. Snapshotting volatile timestamps makes tests brittle.

Classify each failure as a contract violation, transient operational failure, permanent dependency response, concurrency conflict, or programmer defect. That classification determines whether to reject, retry, compensate, cancel, or fail fast. A generic catch-and-continue policy destroys the information needed to make that decision.

Run focused unit tests quickly and a smaller integration suite at build gates. Include unauthorized, forbidden, malformed, conflict, not-found, successful, and persistence-reload paths. Keep failure output useful enough to reproduce locally.

Finish by making the result operable. Add structured diagnostics at the boundary, propagate cancellation, avoid sensitive data, and record SDK and dependency versions. Test the public behavior instead of private implementation details. If a framework or provider performs translation, serialization, concurrency, or I/O, include at least one test against the real production technology.

A senior-level review should be able to answer four questions: what contract is promised, who owns lifetime and cleanup, how failures become visible, and what evidence supports the design. If any answer depends on “the framework probably handles it,” inspect the documentation or runtime behavior and turn the assumption into a checked decision.