rays/ipx
1
0
Fork 0
Code Issues 11 Pull Requests Actions Packages Projects Releases 20 Wiki Activity

The API's coverage is measured, and every suite's is in Grafana (#394)

Browse Source 
The cargo tests put web.rs at 17% and daemon.rs at 10%, because the
browser suite, which drives the API, ran a daemon nobody measured.
`sh scripts/coverage.sh api` builds an instrumented ipx and
ipx-directory in the capped coverage container and runs the browser
suite here against them (IPX_API_COVERAGE): web.rs is at 80% and
daemon.rs at 77%. What it does not reach: access.rs (Cloudflare Access,
0%; its unit tests 73%) and the directory's public pages (site.rs, 4%).

The coverage image is Ubuntu 24.04 now, as code-server is: built on
Debian trixie, the binaries needed glibc 2.41 and code-server has 2.39.
In that mode the suite starts those binaries rather than building its
own, its tests' `ipx` commands too (global-setup's IPX_BIN), passes
LLVM_PROFILE_FILE to both servers, and stops them with SIGTERM, since
an instrumented binary writes its profile as it exits and Playwright
otherwise kills them outright.

Reports go to target/coverage/cargo, api and page. Each run ends with
scripts/coverage-metrics.ts, which writes every suite's lines covered
and in all, by crate, to node-exporter's textfile directory; the
monitoring project's node-exporter now reads it (one flag, its compose
file backed up beside it), so Prometheus keeps them as
ipx_coverage_lines, and the iPX dashboard's Coverage row draws them:
each suite now, over time, and by part. The cargo tests' totals hold
their own code, which runs whole, so they read higher than the code
alone; the panels say so.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Ray Slakinski
2026-11-07 03:33:49 +00:00
parent 352e2b77a5
commit 194a9250e7
10 changed files with 226 additions and 47 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
CLAUDE.md
View File

@@ -209,6 +209,7 @@ node tests/contrast.ts # every theme's palette against WCAG AA
npx playwright test # the browser tests, against a real daemon on fixture feeds
node tests/load/run.ts # k6: many people at once against a scratch daemon with 1,500 feeds
sh scripts/coverage.sh # which Rust lines the cargo tests reach, capped like a build (#390)
sh scripts/coverage.sh api # which Rust lines the browser suite reaches through the API (#394)
npm run coverage:page # which lines of web/src the browser tests reach (#390)
```
@@ -287,17 +288,26 @@ seeking through files, a flood of wrong passwords. Things about them:
* The Rust tests run on Postgres with the same URL: `. /src/.envrc && cargo test`. Each test
makes a schema `ipxt_<pid>_<n>`, and the next run drops those an earlier one left.
Coverage (#390) says what the tests leave untested; read it before deciding a change is covered.
`scripts/coverage.sh` runs the Rust tests instrumented in the `ipx-coverage` image
Coverage (#390, #394) says what the tests leave untested; read it before deciding a change is
covered. `sh scripts/coverage.sh` runs the cargo tests instrumented in the `ipx-coverage` image
(`sh scripts/build-image.sh coverage` makes it), in a container held to the builder's 6 GB and six
threads, one crate at a time, and writes `target/coverage/summary.txt`, `lcov.info` and
`html/`. Its first run rebuilds every dependency instrumented, in a target of its own; later
ones only what changed. It measures the cargo tests alone: the API handlers (`web.rs`) and the daemon run
under the browser suite, whose daemon is not instrumented, so their low numbers there say little.
`npm run coverage:page` is the browser suite on a build of the page that keeps a source map to
each `web/src` file (`IPX_COVERAGE=1`, `web/concat-map.mts`), and writes `target/coverage/page`.
The specs take `test` and `expect` from `tests/ui/coverage.ts`, not from `@playwright/test`, so
every test is counted. The service worker, the unit tests and the native-bridge check are not.
threads, one crate at a time, into `target/coverage/cargo` (`summary.txt`, `lcov.info`, `html/`).
`sh scripts/coverage.sh api` builds an instrumented ipx and ipx-directory there and runs the
browser suite here against them (`IPX_API_COVERAGE`), into `target/coverage/api`: what the API
and the daemon really run, which the cargo tests alone put at 17% for `web.rs`. The image is
Ubuntu 24.04, as code-server is, or the binaries it builds would not start here (glibc); the
suite stops its servers with SIGTERM in that mode, since an instrumented binary writes its profile
as it exits. The same run measures the page; `npm run coverage:page` does that alone, on a build of
the page with a source map to each `web/src` file (`IPX_COVERAGE=1`, `web/concat-map.mts`), into
`target/coverage/page`. The specs take `test` and `expect` from `tests/ui/coverage.ts`, not from
`@playwright/test`, so every test is counted. The service worker, the unit tests and the
native-bridge check are not.
Each run ends with `node scripts/coverage-metrics.ts`, which writes every suite's last numbers to
`/mnt/fast/appdata/node-exporter/textfile/ipx_coverage.prom`; node-exporter's textfile collector
(the monitoring project's compose file) serves them as `ipx_coverage_lines{suite,part,state}`, job
`node`, and the iPX dashboard's Coverage row draws them. A coverage run started by hand updates
Grafana; nothing runs one on its own.
Non-trivial logic leaves one runnable check behind. Pure functions (`merge_policy`, `pick`,
`matches_keywords`, `parse_interval`) are the easiest place to put it.