Testing and Diagnostics

Testing and diagnostics

Imp page logic can be tested at three levels: application services, page/request behavior, and end-to-end HTTP rendering.

Unit-test services

Keep business logic in injected services and test it without HTTP. The Todo sample tests TodoStore directly, including normalization, state changes, removal, and input limits.

Test routing and binding

The Imp unit tests construct DefaultHttpContext, configure ImpMiddleware, and call Request.CreatePageObject. This is useful for verifying:

• path-to-type mapping;
• root and nested namespaces;
• case behavior;
• query conversion and invalid-value defaults;
• dependency-injected page construction;
• custom not-found types.

When adding a supported binding type or changing routing semantics, extend these contract tests.

HTTP integration tests

Use WebApplicationFactory<Program> or run the host on an ephemeral local port. Verify:

• expected status and content type;
• template output and encoded user values;
• actual static asset URLs;
• authenticated/unauthenticated secure-page behavior;
• valid and invalid antiforgery submissions;
• fallback permalink resolution;
• missing-record and unknown-route 404 responses;
• lifecycle headers or other global hooks.

Integration tests are especially valuable because they exercise Kestrel response restrictions and embedded-resource naming—problems a memory-stream unit test may not reveal.

Logging

Imp logs through the standard Microsoft.Extensions.Logging abstractions. Configure providers and category levels through the ASP.NET Core host. The category for Imp request and page-creation messages is Imp.ImpMiddleware.

For example, appsettings.json can enable informational Imp messages while leaving the application's default threshold at warning:

{
  "Logging": {
    "LogLevel": {
      "Default": "Warning",
      "Imp.ImpMiddleware": "Information"
    }
  }
}

Avoid verbose request logging in production when URLs may contain sensitive values. Imp logs the request path but not its query string. Correlate framework and application logs with request IDs when diagnosing a request.

Development failure strategy

Template compilation errors indicate code/resource mismatch and should fail visibly in development. Enable the developer exception page only in development. In production, use exception handling before Imp and return a generic error page without exposing stack traces.

CI checks

The repository workflow installs .NET 8 and .NET 10, restores, builds, runs the multi-targeted unit and Kestrel integration tests, packs, validates package consumers for both target frameworks, and uploads a prerelease NuGet artifact. NuGet restore fails the build when it reports a dependency vulnerability.