Iwf Guide
Testing and Debugging
Iwf provides pure route/handler helpers, framework specs, canonical app HTTP end-to-end tests, and focused acceptance harnesses.
1. Framework Tests
Run all framework checks directly:
sh tests/scripts/run
The visible specs live under:
tests/src/Tests
They cover HTTP parsing, routes, forms, uploads/storage, CSRF, auth, sessions, cookies, flash, JSON, OpenAPI, static assets, pagination, config, Auto Refresh, typegen/migrations, TypedSQL, and the canonical example app.
2. Acceptance Harnesses
Use targeted harnesses for high-risk framework contracts:
tests/scripts/acceptance shell htmx-fragments typed-forms typedsql-postgres auto-refresh-races
The TypedSQL harness builds the compile-pass fixtures in addition to the focused spec group.
3. App Tests
The canonical app test script:
cd examples/canonical
iwf check
It installs the local framework into .iwf/idris2, preprocesses IDRX into build/generated, regenerates schema types, ensures PostgreSQL is available for the TypedSQL describe preflight, builds the app, starts the canonical server, and runs HTTP checks against real endpoints.
4. Iwf.Test
Use pure helpers for route and handler tests:
testGettestPosttestJsonPostrunRoutesassertStatusassertBodyassertHeader
Example shape:
testHome : IO ()
testHome = do
let response = runRoutes routes (testGet "/")
assertStatus 200 response
assertBody "Iwf" response
5. Diagnostics
Iwf.Diagnostic renders readable framework diagnostics for:
- route macro errors
- migration errors
- form errors
- auth errors
- database typegen errors
Iwf.Log emits colorized request/response logs through the server by default; set the logging config to structured mode if you need a single-line format.
6. Browser Debugging
For boosted form bugs, inspect the real request:
HX-RequestHX-BoostedContent-Type- encoded request body
- response status
LocationHX-RedirectHX-Refresh
Browser form posts use application/x-www-form-urlencoded; encoded characters such as %40 must decode before validation.
Next
Read Troubleshooting.