Testing

Testing an action's Rust return value alone does not validate its HTTP contract. Also check status, headers, body, and shutdown behavior.

A small validation flow#

Run the first application. For GET /api/hello, verify 200, a JSON content type, and the expected body. Then check 404 for a missing path, 405/Allow for an unsupported method, and a bodyless response for HEAD.

curl -i http://127.0.0.1:8080/api/hello
curl -I http://127.0.0.1:8080/api/hello
curl -i -X POST http://127.0.0.1:8080/api/hello
curl -i http://127.0.0.1:8080/olmayan-yol

In automated integration tests, do not assume readiness based only on a fixed sleep. Wait for readiness with a bound, shut down through external cancellation or close, and await the shutdown result.

DI and policy tests#

seed_singleton can provide a controlled initial value for a registered Singleton. Test scope sharing, interface resolution, and invalid lifetime errors. Seeding does not add new service registrations at runtime.

For authentication/authorization, verify valid, missing, malformed, and unauthorized credentials separately. Rate limiting should return 429 for actual quota exhaustion and 503 for store failure. Test cookies and CSRF together, accounting for browser credential behavior.

Run framework tests#

To run framework tests, use Rust 1.96.1 in a checkout of the public repository at this guide's source commit. This checkout is not a prerequisite for installing your application:

cargo test -p lily_http_api \
  --test typed_action_executor \
  --test typed_service_executor \
  --test typed_response_modes \
  --test typed_multipart_executor \
  --test openapi_service_publication \
  --test openapi_schema_security \
  --test execution_cancellation

Add --offline when the local dependency cache is complete. These tests require an environment that permits loopback sockets. Do not use internal Handler/RouteTable constructors as if they were your application's public startup API.

Validate integration features in separate profiles. For example, postgresql and postgresql-factory cannot be enabled in the same build. Using --all-features or features unified across an entire workspace does not validate an individual application profile. The framework's versioned facade qualification guide explains isolated consumers and feature profiles.

Validation coverage of this guide#

Postpublication example validation: During this facade update, the 15 downloadable HTTP Rust examples compiled in separate Cargo projects using Rust 1.96.1. Lily dependencies resolved exclusively from crates.io at 0.1.0; no local framework checkout or dependency patch was used. PostgreSQL, MongoDB, and Redis examples passed compilation within this scope; live data operations were not exercised.

Three local HTTP tests also passed: GET /api/hello returned 200 in the first application; GET /greetings resolved Singleton and Scoped services in the DI example; and POST /users returned 201, Location: /users/42, and the expected JSON in the typed-request example. The tests shut the host down through cancellation and awaited shutdown completion. They also confirmed that an action path of / does not add a trailing slash to the combined controller path.

The documentation repository's docs/lilyrs-ornek-dogrulama.json records example hashes, dependency profiles, and outcomes. From that repository, you can rerun a sample compilation and the three HTTP behavior checks:

python3 scripts/check-rust-examples.py --profile http-first-app
python3 scripts/check-rust-examples.py --mode smoke --profile http-first-app --profile http-di --profile http-requests

Historical validation — 14 September 2026: On checkout fabed7e8b9ad140528e1254e91c023a7059b927d, 15 complete Rust examples compiled and 12 HTTP integration tests in the targets above passed. Global middleware repetition was also exercised with a public API probe. These results predate the facade migration; they do not mean the updated examples were rerun against the published lilyrs package.

Framework release validation — 18 September 2026: The source repository's release qualification report records its own coverage of package archives, facade profiles, component tests, and live application checks. This is the framework team's prepublication work; do not assume that every code fragment on this site participated in those tests or was retested in that report.

The initial site review did not run data mutation/transaction tests against live PostgreSQL, MongoDB, or Redis. Its integration validation was limited to API/derive review and compilation. Live tests in the framework report are not live test results for these teaching examples. The reference records the source revision and example boundaries.