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 uses log4net internally. Configure log4net in the host when route and lifecycle messages are useful. Avoid verbose request logging in production when URLs may contain sensitive query values.

ASP.NET Core hosting, static files, authentication, and exception middleware log through the normal Microsoft logging abstractions. Correlate those logs with request IDs.

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 restores, builds, tests, packs, and uploads a prerelease NuGet artifact. A documentation/example change should still build the entire solution because embedded resources and project paths are validated at compile/package time.