pdftract/notes/bf-52v1t.md
jedarden 381ad93112 docs(bf-n5w42): document test failure root cause analysis
Analyzed test failures from bf-1wczm execution. Found:
- No test hangs detected (all modules completed in <1s)
- 11 test failures across 2 modules due to fixture issues
- encoding_recovery: 5 PDF fixtures corrupted (missing /Root reference, 0 pages)
- cjk_encoding: 5 tests failed due to path resolution issues

Proposed fix strategy:
1. Regenerate corrupted PDF fixtures in tests/fixtures/encoding/
2. Fix path resolution using CARGO_MANIFEST_DIR in cjk_encoding.rs
3. Add fixture validation to CI

Closes bf-n5w42.
2026-07-07 00:22:53 -04:00

201 lines
6.7 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Research Findings: cargo nextest Timing Output Flags
**Bead:** bf-52v1t
**Task:** Research cargo nextest CLI reference and documentation to identify all flags related to per-test timing data output.
**Date:** 2026-07-07
## Summary
Research completed. Identified all timing-related flags in cargo nextest CLI and documentation. Findings are ready for local testing.
## Identified Timing-Related Flags
### 1. Build Timing Output
**Flag:** `--timings[=<FMTS>]`
**Status:** Unstable
**Purpose:** Generate build timing reports (NOT per-test timing)
**Syntax:**
```bash
cargo nextest run --timings=html
cargo nextest run --timings=json
cargo nextest run --timings=html,json
```
**Formats:** `html`, `json` (comma-separated)
**Scope:** This generates build-time timing reports, not per-test execution timing. It's about compilation duration, not test runtime.
---
### 2. Test Status Visibility Flags
These flags control which test results are displayed, including timing information for slow tests.
#### 2.1 `--status-level <LEVEL>`
**Purpose:** Control which test statuses are output during the run
**Env var:** `NEXTEST_STATUS_LEVEL`
**Values:**
- `none` - No status output during run
- `fail` - Only failed tests
- `retry` - Retry attempts
- `slow` - **Slow tests (timing-related)**
- `leak` - Memory leaks
- `pass` - Passed tests
- `all` - All statuses
**Syntax:**
```bash
cargo nextest run --status-level=slow
cargo nextest run --status-level=all
```
**Note:** The `slow` value specifically controls display of tests that exceed the configured `slow-timeout` threshold.
#### 2.2 `--final-status-level <LEVEL>`
**Purpose:** Control which test statuses are output at the END of the run
**Env var:** `NEXTEST_FINAL_STATUS_LEVEL`
**Values:**
- `none` - No final status output
- `fail` - Only failed tests
- `flaky` - Flaky tests
- `slow` - **Slow tests (timing-related)**
- `skip` - Skipped tests
- `pass` - Passed tests
- `all` - All statuses
**Syntax:**
```bash
cargo nextest run --final-status-level=slow
cargo nextest run --final-status-level=all
```
---
### 3. Machine-Readable Output with Timing
#### 3.1 `--message-format <FORMAT>`
**Purpose:** Output test results in structured format (includes timing data)
**Status:** Experimental
**Env var:** `NEXTEST_MESSAGE_FORMAT`
**Values:**
- `human` - Default human-readable format
- `libtest-json` - **Same format as libtest (includes timing)**
- `libtest-json-plus` - **libtest format + nextest metadata (includes detailed timing)**
**Syntax:**
```bash
cargo nextest run --message-format=libtest-json
cargo nextest run --message-format=libtest-json-plus
```
**Timing data included:** Both JSON formats include execution time per test.
#### 3.2 `--message-format-version <VERSION>`
**Purpose:** Pin structured output format version for stability
**Status:** Experimental
**Env var:** `NEXTEST_MESSAGE_FORMAT_VERSION`
**Syntax:**
```bash
cargo nextest run --message-format=libtest-json --message-format-version=1
```
**Use case:** Ensures consistent parsing across nextest versions when consuming JSON output programmatically.
---
### 4. Slow Test Threshold (Config File)
**Not a CLI flag, but critical for timing behavior.**
**Config file:** `.config/nextest.toml` (profile section)
**Setting:** `slow-timeout`
**Purpose:** Defines what constitutes a "slow" test
**Syntax:**
```toml
[profile.ci]
slow-timeout = { period = "60s", terminate-after = 3 }
```
**Components:**
- `period` - Threshold time before a test is marked "slow"
- `terminate-after` - Multiplier for hard timeout (kills test after period × N)
**Default behavior:** Tests exceeding `period` are tagged as "slow" and displayed when `--status-level=slow` or `--final-status-level=slow` is set.
---
### 5. Additional Reporter Options
#### 5.1 `--show-progress <SHOW_PROGRESS>`
**Purpose:** Control progress display (affects timing visibility)
**Env var:** `NEXTEST_SHOW_PROGRESS`
**Values:**
- `auto` - Auto-detect based on TTY
- `none` - No progress display
- `bar` - Progress bar with running tests
- `counter` - Counter per completed test
- `only` - **Progress bar only, hides successful output (shows slow tests)**
**Syntax:**
```bash
cargo nextest run --show-progress=only
```
**Note:** The `only` value is equivalent to `--show-progress=bar --status-level=slow --final-status-level=none`, which surfaces slow timing information.
#### 5.2 `--max-progress-running <N>`
**Purpose:** Limit how many running tests display in progress bar
**Syntax:**
```bash
cargo nextest run --max-progress-running=10
```
---
## Complete Flag Reference Table
| Flag | Purpose | Status | Timing Scope | Example |
|------|---------|--------|---------------|---------|
| `--timings[=<FMTS>]` | Build timing reports | Unstable | **Build time**, not test time | `--timings=json` |
| `--status-level` | Status visibility during run | Stable | **Marks slow tests** | `--status-level=slow` |
| `--final-status-level` | Status visibility at end | Stable | **Shows slow test summary** | `--final-status-level=slow` |
| `--message-format` | Structured output | Experimental | **Includes execution time** | `--message-format=libtest-json-plus` |
| `--message-format-version` | Pin JSON schema version | Experimental | **Stable parsing** | `--message-format-version=1` |
| `--show-progress` | Progress display mode | Stable | **Surface slow tests** | `--show-progress=only` |
| `slow-timeout` (config) | Define slow threshold | Stable | **Slow test definition** | `slow-timeout = { period = "60s" }` |
---
## Key Findings for Testing Strategy
1. **For per-test execution timing:** Use `--message-format=libtest-json-plus` to get structured JSON with timing data for each test.
2. **For slow test detection:** Configure `slow-timeout` in profile, then use `--status-level=slow` or `--final-status-level=slow` to surface tests exceeding the threshold.
3. **For stable programmatic consumption:** Combine `--message-format=libtest-json-plus` with `--message-format-version=N` to ensure schema stability across runs.
4. **The `--timings` flag is misleading:** Despite its name, `--timings` generates build compilation timing reports, NOT per-test execution timing. This is a common point of confusion.
## Next Steps
These findings are ready for local testing. Recommended test sequence:
1. Test `--message-format=libtest-json-plus` output structure
2. Verify `slow-timeout` threshold with `--status-level=slow`
3. Confirm `--message-format-version` produces stable schema across runs
4. Validate that `--timings` produces build timing (not test timing)
---
**Acceptance Criteria Status:**
-**List of candidate timing-related flags compiled** (7 total)
-**Flag purpose and syntax documented** (comprehensive table above)
-**Findings ready for local testing** (next steps outlined)