## Linked issue (required)
Refs #5134
## Summary / motivation (required)
When running ci, instead of manually compiling cargo-llvm-cov and
cargo-nextest when not cached, this pr pulls them in as prebuilt
binaries instead
## Steps to reproduce (required, use N/A if not applicable)
N/A
## How to test (required)
CI should pass, and running `./check` and `just test --coverage` should
work locally too
### Checklist (minimum)
- [x] I ran `./ninja check` or an equivalent relevant check locally.
- [ ] I added or updated tests when the change is non-trivial or
behavior changed.
### Details
Continuing from
https://github.com/ankitects/anki/issues/5134#issuecomment-4936603431,
we can avoid installing the crates globally when run locally, but in ci
it doesn't really matter so we can use install-action as per normal.
W.r.t nextest's features, all `default-no-update` does is remove its
ability to self-update. Since we're puling in prebuilt binaries during
ci there's no difference
I've left out n2 for now, as without a release workflow on its repo or
on anki's fork, we'd still have to compile it ourselves (caching it can
be unsafe, but it sort of is already cached by setup-rust-toolchain?)
## Scope
- [x] This PR is focused on one change (no unrelated edits).
## Linked issue
Closes#4925
## Summary / motivation
Adds a comprehensive unit test suite for
`rslib/src/notetype/service.rs`, which previously had zero tests. The
file implements the `NotetypesService` gRPC trait for `Collection` — 20
service methods and 6 `From` trait conversions used by both the Qt
frontend (via the legacy JSON adapter path) and the modern proto path.
Tests are organized into five commits by concern:
- **From trait conversions** (`NotetypeId` round-trip,
`ChangeNotetypeRequest ↔ ChangeNotetypeInput` mappings including the `-1
→ None` sentinel and `is_cloze` flag)
- **Legacy JSON adapters** (`add_notetype_legacy`,
`update_notetype_legacy`, `get_notetype_legacy`,
`get_stock_notetype_legacy` for all 6 stock kinds, and all 3 branches of
`add_or_update_notetype`)
- **CRUD service methods** (add, get, update, remove — happy paths,
error paths, and side effects such as card generation when a template is
added)
- **Auxiliary methods** (`get_notetype_names_and_counts`,
`get_aux_notetype_config_key`, `get_aux_template_config_key` including
the Cloze branch and the error path for unknown IDs)
- **Coverage threshold bump** (60 → 64)
## How to test
### Details
```bash
cargo test -p anki --lib "notetype::service::tests"
```
---------
Co-authored-by: Abdo <abdo@abdnh.net>
## Linked issue
Closes#4928
## Summary / motivation
`learning.rs` and `relearning.rs` had 0% test coverage. They implement
the core scheduling logic for new and lapsed cards — a regression here
affects every user's review queue silently. This PR adds unit tests to
establish a safety net before future migrations or FSRS changes touch
this code.
## How to test
```bash
cargo test -p anki --lib "states::learning::tests"
cargo test -p anki --lib "states::relearning::tests"
```
## Details
`learning.rs` — tests covering all four buttons under SM-2: again (reset
to first step, no-steps graduation), hard (same step, no-steps
graduation), good (advance or graduate), easy (always graduates,
interval ordering invariant), plus FSRS routing stubs.
`relearning.rs` — tests covering SM-2 transitions (lapse penalty, step
keep/reset/graduate), FSRS routing (long interval → Review, short-term →
Relearning for all buttons), and multi-step behavior (again resets, hard
keeps, good advances through intermediate steps).
## Linked issue
Closes#4874
## Summary / motivation
Adds `tools/coverage/check-coverage-regression.py` to compare line
coverage percentages from the current PR against the baseline saved from
main (introduced in #4875). If any stack regresses beyond the
configured tolerance (0.10%), the CI fails with a clear message showing
the delta.
Stacks checked: Rust, python-pylib, python-qt, TypeScript.
## How to test
Try to add some new code without any tests. The Ci must fail.
## Before / after behavior
Before: no signal when a PR reduces coverage below the current main
level.
After: CI fails on `Check coverage regression` with output like:
```
[rust] REGRESSION: 62.64% -> 61.00% (delta: -1.64%, tolerance: 0.10%)
1 stack(s) with coverage regression: rust
```
## Linked issue
Closes#4859
## Summary
Add tests for the build_installer.py script with 100% coverage.
## How to test
Run `just test-py --coverage --html` and browse coverage data.
## Linked issue
Closes#4840
## Summary / motivation
Adds Vitest V8 coverage for TypeScript/Svelte tests via
`@vitest/coverage-v8`.
Introduces `just test-ts --coverage` and `just test-ts --coverage
--html`,
and wires TypeScript into the `just test --coverage` umbrella —
completing
coverage support across all three stacks (Python, Rust, TypeScript).
The threshold is set to 5% — intentionally low because the Vitest test
count is small relative to the TypeScript/Svelte source surface. It is
meant to be raised as more tests are added.
## How to test
```sh
# Existing behavior unchanged
just test-ts
# Terminal summary + enforces 5% line coverage threshold
just test-ts --coverage
# Terminal summary + HTML report under out/coverage/typescript/
just test-ts --coverage --html
# Full umbrella — all three stacks
just test --coverage
just test --coverage --html
```
### Checklist
- [x] I ran `./ninja check` or an equivalent relevant check locally.
### Details
- `@vitest/coverage-v8` pinned at `3.2.4` in `package.json`.
- Reports are written to `out/coverage/typescript/` via
`--coverage.reportsDirectory=../out/coverage/typescript` (relative to
the `ts/` working directory where vitest runs).
- V8 provider is preferred over Istanbul: faster and requires no Babel
transform for TypeScript projects.
- Coverage measures only code reachable through Vitest's module graph —
Svelte component rendering is not covered.
- The `yarn` justfile variable is added for platform-aware yarn
invocation (Windows vs Unix).
## Before / after behavior
Before: no `just test-ts`, no TypeScript coverage.
After: `just test-ts` runs Vitest via ninja; `just test-ts --coverage`
runs with V8 instrumentation.
`just test --coverage` now spans all three stacks.
---------
Co-authored-by: Abdo <abdo@abdnh.net>
## Linked issue
Closes#4839
## Summary / motivation
Adds `cargo-llvm-cov`-based test coverage for the full Rust workspace.
Introduces `just test-rust --coverage` and `just test-rust --coverage
--html`, and wires Rust into the `just test --coverage` umbrella.
`cargo-llvm-cov` is installed on demand into `out/bin/` to avoid
polluting the global cargo install. The `llvm-tools-preview` rustup
component is now installed in CI so the tool can instrument binaries.
## How to test (required)
```sh
# Existing behavior unchanged
just test-rust
# Terminal summary
just test-rust --coverage
# Terminal summary + HTML report under out/coverage/rust/html/
just test-rust --coverage --html
# Umbrella (Rust + Python)
just test --coverage
just test --coverage --html
```
Note: first run of `--coverage` will install `cargo-llvm-cov` into
`out/bin/` (~30s). Subsequent runs skip the install step.
### Checklist
- [x] I ran `./ninja check` or an equivalent relevant check locally.
### Details
- `cargo-llvm-cov` pinned at `0.8.4`, installed into `out/bin/` via
`cargo install --root out`.
- `--workspace --locked` measures all crates and respects the lockfile.
- `llvm-tools-preview` added to `setup-anki` action so CI can instrument
Rust binaries.
- Coverage runs are slower than plain `just test-rust` because
`cargo-llvm-cov` rebuilds with instrumentation — this is expected.
## Before / after behavior
Before: no `just test-rust`, no Rust coverage support.
After: `just test-rust` runs Rust tests via ninja; `just test-rust
--coverage` runs them with `cargo-llvm-cov`
---------
Co-authored-by: Abdo <abdo@abdnh.net>
