Jadpo is experimental and not ready for production. These docs follow the compiler's main branch as of 30 Oct 2026. What's built · Install 0.1.0
jadpo
Reference: Debugging and review

Debugging and review

Capturing a failing request as a test

On this page

The quickest reliable fix starts by reproducing the bug. jadpo test new --from <request id> writes a route test that replays a request jadpo dev recorded, with the data the request read written as fixtures, the test data a test starts from. The test asserts what was observed. You change the assertion to what should happen, watch the test fail, then fix the code. Your agent can do the whole loop.

example
// domains/planning/routes/todos.test.jadpo/// Captured from req_0b1e by jadpo test new --from.test "completing a todo twice answers a conflict" {    clock: "2026-10-12T09:14:03Z"    var alice: Principal.user = captured_user_1()    var todo: Todo = captured_todo_1(alice)    var response: Response = request {        method: HttpMethod.post        path: "/todos/{todo_id}/complete"        params: {            todo_id: todo.id        }        as: alice    }    // observed: 409 todo_mutation_conflict    assert response.status == 409    assert response.code == "todo_mutation_conflict"}

What the captured test holds

  • Fixtures go in the domain's fixtures/ folder and create records through the entity's generated operations (Shared test data: fixtures).
  • Personal data is never copied. Fields marked personal: are replaced with generated values, so a captured test never commits real personal data (Marking personal fields).
  • Calls to providers become fakes: that give the answers the request received.

From a production event

--from-event <file> does the same from a production event. It uses only what the event recorded, so it can't write the fixtures; you fill those in yourself.

Markdown for agents: /docs/capturing-a-failing-request-as-a-test.md.Built from Jadpo main at a707efb.