Test coverage map

Where the tests are, where they are thin, and what to write next. The page is the answer to “which code can break without a test noticing?” – it is meant to be updated, not admired. Whether the tests check what they run is the job of mutation testing. Last measured: 2026-11-06, from the CI job coverage on main at b4cf014 (release 0.2.0; it contains #89–#95 and the proofing tests).

Method

• Lines of code – wc -l of every file under src/ (blank lines and comments included) and desktop/src/.

• Unit tests – the number of #[test] / #[tokio::test] functions in the module’s own file (src/simmesh/tests.rs belongs to simmesh.rs).

• Integration tests – tests/*.rs talk to the real router (HTTP), so the routes and services they reach are mapped by what the test asserts, not by imports. The module table names only the test files that use a module directly (teamcraft::module::…); the area tables list the test files that drive the code through the API or the web UI.

• Measured line coverage – cargo llvm-cov in the CI job coverage: the complete test suite (unit, integration and database tests) against PostgreSQL 16 with the client tools. Its per-file summary is the source of the tables below. Locally, without a database, a quick check is:

  cargo install cargo-llvm-cov --locked && rustup component add llvm-tools-preview
  cargo llvm-cov --lib --summary-only            # unit tests only
  cargo llvm-cov --summary-only --no-fail-fast   # every test that runs without PostgreSQL
  cargo llvm-cov --html                          # report in target/llvm-cov/html
  

  Without PostgreSQL the database tests skip themselves, so services/*, web/* and api/* look uncovered locally although CI exercises them. Inline #[cfg(test)] code counts as covered lines, so the percentage of a module with a large test section is too high – the number of missed lines is the honest figure.

• Ranking – risk × thinness. Risk: untrusted input (file parsers, HTTP bodies, tokens), data integrity (multi-row mutations, vault, backup, migrations, imports, uploads), size of the code. Thinness: missed lines, and whether failure paths (refusal, conflict, rollback, damaged input) are tested at all and not only the happy path.

Coverage in CI

The PostgreSQL 18 leg of the job tests in .github/workflows/ci.yml (until 2026-11-07 a separate job coverage) runs cargo llvm-cov over the complete test suite with PostgreSQL 18 and the client tools, prints the per-file summary into the job summary and uploads the HTML report (coverage-html, 14 days) as an artifact.

The floor. Since 2026-11-06 the job fails when the total line coverage drops below the value in .github/coverage-floor. The last runs on main were 91.48 % (6b7c95a), 91.52 % (e513b37), 91.53 % (5a39a85) and 91.65 % (0fcfa26, b4cf014): the variation between runs is about a tenth of a point, so the floor is the current value minus half a percentage point – 91.1 %, about 280 missed lines more than today. Raise it when the coverage has grown for good; lowering it is a deliberate change of that file in the pull request, with the reason in its description.

Areas

Missed lines / lines and line coverage from CI (b4cf014).

Feature to test map

Every file in tests/ (2026-11-06, ab1abd9), grouped by the feature it pins. The count is the number of #[test] / #[tokio::test] functions in the file (grep -c "#\[test\]\|#\[tokio::test\]"); it is a size hint, not a measure of quality. The CI numbers in the tables above are still from b4cf014.

Unit tests in src/, by feature (count of test functions in the module or its tests file):

Services and pages with no unit test (services/items, changes, revisions, interchange, attributes, insights, projects, explorer, references, workset, save_as, package, stats; every web/* and api/* module): they are covered through the HTTP tests above only.

Gaps

Judged by the test counts above, the missed lines of the CI table and whether a failure path has a test. Ordered by risk.

1. Vault explorer (services/explorer.rs, web/explorer.rs): no test file of its own and no unit test; only api_flow, web_ui and scale touch it.
2. Projects and self-service groups (services/projects.rs, 53 of 558 lines missed): no own file and no unit test; the failure paths (a refused change by a non-manager, a removed member keeping access) are the ones to pin, in a new projects file.
3. Simulations (services/simulations.rs 85 missed, web/simulations.rs 74.6 %, api/simulations.rs 90.7 %): five unit tests and no own file.
4. Change requests triage (services/requests.rs, 162 missed; web/requests.rs, 131 missed at 75.1 %): one integration test for the paths, the triage pages are untested except through web_ui.
5. Admin and account pages (web/admin.rs 74.3 %, 110 missed; web/account.rs 83.4 %; web/personal.rs 80.7 %): no own file, no unit test.
6. Attributes and interchange (2 integration tests each, no unit test; web/attributes.rs 75 %, web/interchange.rs 88 %): the failure paths to add are a refused edit by a non-administrator and a conflicting alternate.
7. Search, watches, reviewers (1 to 2 tests each): the failure paths to add are a filter that must not reveal a restricted item and a watch on a removed item.
8. Identity and notifications with real servers: oidc.rs 53.5 % (CI), notify.rs 26 % (CI, before tests/notify.rs), no test against a real SMTP or Mattermost server; services/users.rs 72.9 % (187 missed) for deactivation and token revocation of a whole account.
9. Range downloads (tests/range_downloads.rs, 1 test): httprange is at 100 % line coverage, but the file-level test count is the thinnest of the download path; the failure path to add is a resume whose If-Range no longer matches the stored object.

Next tests come from these items in the order above, failure path first (refusal, conflict, rollback).

Top 15: the thinnest high-risk spots

Ranked by risk × thinness on 2026-11-05; the last two columns are today’s state.

Thin, outside the top 15: services/requests.rs (162 of 1,587 lines missed), web/requests.rs, web/simulations.rs, web/attributes.rs and web/admin.rs (a quarter of their lines missed each), desktop/src/commands.rs. Covered since (the numbers in the table below are from before, until the next coverage run):

• notify.rs (48 of 65 missed) – tests/notify.rs: an internal error of a request reaches a local stand-in for Mattermost, further errors within the minute are only counted, a receiver answering 500 changes nothing; unit tests for the rate limit (with the clock passed in) and the message.
• services/insights.rs (83 of 187) – tests/insights.rs: every kind of BOM issue once per line, the released rule, a cycle, a hidden line reported without its number, an empty BOM, the cap of 500 findings; duplicate files with and without a scope, for a reader and an administrator.
• web/webhooks.rs (48 of 216) – tests/web_webhooks.rs: every page and action for a non-administrator and from another site, the form rules (including internal addresses as IP literals), test delivery, retry (409 for a sent delivery and an inactive webhook), secret rotation, deletion.

Found while writing the tests

• Fixed (2026-11-05) – mesh::read("gltf", …) panicked (index out of bounds inside gltf-json) for a primitive whose POSITION points past the accessor list. The library call is now wrapped in catch_unwind and yields an error; regression test gltf_accessor_index_out_of_range_is_an_error.
• Fixed (#93) – backup::backup copied vault objects without checking their hash and did not require the objects the database refers to; a corrupt or missing object was found only at restore time. The backup now refuses both and removes what it wrote.
• Fixed (2026-11-06) – the commands of the CLI wrote their log lines (e.g. the audit line of user create) to standard output, between their own output. They now log to standard error; the server still logs to standard output (tests/cli.rs).
• No bug (#92) – every multi-row mutation covered by atomic_processes already ran in one transaction; a mutation check (a check-in split into two transactions) makes those tests fail.
• Fixed – a login code the identity provider refused (invalid_grant: a code already used or expired, or a PKCE verifier that does not match – an intercepted code) ended in a 500 page and an incident report. It is a failed login attempt, not a server fault: it is now the login page with a 400 and “the identity provider refused the login code”; other token endpoint errors (invalid_client, a 5xx, no connection) stay internal errors because the administrator has to act. Regression tests a_pkce_mismatch_or_a_used_code_is_refused_by_the_provider and a_misconfigured_client_stays_a_server_error.
• Observation, decision left open – ID token signatures are not verified; that rests on the token coming straight from the token endpoint over TLS (OIDC Core 3.1.3.7 step 6). TEAMCRAFT_OIDC_ISSUER_URL also accepts http:// (an internal identity provider without TLS); then nothing protects the token on its way. Refusing http:// outside of localhost, or verifying the signature against the provider’s JWKS when the issuer is plain HTTP, would close that – not changed here because it can break existing installations.
• Fixed (2026-11-06) – insights::duplicate_files with a revision of a group the reader may not see answered with the visible copies of its files (only the MCP tool checked the revision first). The service now answers “not found” itself (tests/insights.rs).
• No bug – a webhook URL with a host name such as localhost is saved: only IP literals are checked then, the name when the connection is made (tests/webhook_ssrf.rs).
• No bug – the SSRF check at connect time: the resolver filters every answer for each new connection; a mutation that drops the filter fails the four resolver-based tests.

What to write next

1. services/requests.rs and the thin web pages (web/requests.rs, web/simulations.rs, web/attributes.rs, web/admin.rs).
2. FRD sample and a SOLIDWORKS container built by hand in the damage tests.
3. Done: the CLI (main.rs, 511 of 643 lines missed) – tests/cli.rs runs the real binary against a test database (migrate, user, vault check, rescan-references, assistant check, healthcheck, preview-mesh, text-extract, the mcp bridge), which the coverage job measures; serve, backup/restore (see backup_restore) and vault signatures still run only elsewhere.
4. Done: atomicity under an injected failure (#92), a floor for the CI coverage job (.github/coverage-floor), OIDC failure paths and the SSRF check at connect time (oidc_flow, webhook_ssrf), cargo fuzz targets (see Fuzzing the file readers), error notifications, BOM health check and duplicates, webhook pages (notify, insights, web_webhooks).

Per module

From the CI job coverage on b4cf014. Integration names the test files that use the module by name (teamcraft::…); the HTTP-driven coverage of services/*, web/* and api/* is in the area table above.