What problem does it solve?
This Skill prevents flaky or misleading Axum tests by ensuring every test drives the same fully configured app wiring, with correct handling of JSON request content types and response body collection. It also avoids common integration-test breakages where tests/ can’t access a private app() constructor, and it fixes compile-time failures caused by reusing a consumed oneshot service across multiple requests.
Core Features & Use Cases
- Shared app() constructor discipline: Route unit and integration tests through one shared
app() (or pub fn app(...)) so tests prove the real shipped wiring.
- Two deterministic testing approaches: Use
tower::ServiceExt::oneshot for fast handler/unit tests or axum-test::TestServer for ergonomic integration tests with fluent assertions.
- Correct JSON and body reading: Set
Content-Type: application/json for raw JSON oneshot requests to avoid MissingJsonContentType/415, and always read response bodies via into_body() + http_body_util::BodyExt::collect() before inspecting bytes.
- Multi-request sequencing: Use
.into_service() plus ready()/call() when you need multiple requests against one app instance.
- Integration test visibility: Export
app() from src/lib.rs so tests/ crates can import it successfully.
Quick Start
Use the axum-impl-testing skill to write a deterministic #[tokio::test] that either sends a JSON request via oneshot with the correct Content-Type header or uses axum-test::TestServer with fluent assertions, all built from a shared pub fn app() constructor.
