What the graph and production evidence add

Each of these joins the compiler's graph to path IDs. Every request records the path it took through your app, the route, each action and query, and each branch taken inside them, as a number the graph can decode (Path IDs). Production data is always an optional input: a file exported from your monitoring tool, or a service that holds it. Every command works without it.

Coverage by path

jadpo test reports which paths your tests ran, not which lines. Line coverage says a branch ran once; path coverage says which combinations of branches ran.

Given production path counts, it also lists the paths that ran in production but have no test, busiest first, and jadpo test new --from writes the missing test. Paths in the graph that production hasn't used for 90 days are listed as candidates for removal.

Production in review

Given production path counts, the approval report says how much a change touches what is in use: "touches paths that served 38% of requests last week; one failed 12 times".

Replaying a production request

Time, randomness, calls to providers and the database are all declared effects, so the runtime knows every source of results that can differ from one run to the next. A deployment can opt in to recording what each effect returned for a failing request:

• only failing requests are recorded;
• personal fields are replaced, using their personal: marks (Marking personal fields);
• the recordings expire, as logs do.

jadpo replay then runs that request on your machine and gets the same results. It extends test new --from from jadpo dev to production.

Query cost of a change

The compiler counts the queries on every path by itself, so the approval report can say "adds 2 queries to POST /orders". Given production counts, it also says which of those paths is busiest.