B2 (#174): read what the progress notification actually says #184

Merged
JMR-dev merged 2 commits from test/notification-progress-text into main 2026-09-02 04:12:35 +00:00
JMR-dev commented 2026-09-02 02:48:39 +00:00 (Migrated from github.com)

Closes #174. Stacked on #183.

An assertion gap rather than a coverage one, which is exactly why it survived. JaCoCo is green on build()'s if (indeterminate) — ProgressNotificationTest drives it through a real worker — but that test reads the notification id and EXTRA_PROGRESS and nothing else. Nothing had ever read the text.

mutation before now
swap the two content texts green red
replace the caller's title with a constant green red

What it costs to get wrong is small and permanent: a conversion four minutes in still saying "Preparing…", or one that has not started reporting yet claiming 0%. Neither is a crash, and nothing else here would have found it.

Why nothing had constructed this class directly

Mechanical, not an oversight: build() reaches WorkManager.getInstance for the Cancel action's PendingIntent, so the notification cannot be built without one. installTestWorkManager in setUp is the whole fixture — and the KDoc records the coupling so the next person does not rediscover it.

areEnabled() is deliberately still untested

It has no caller anywhere in app/src/main. A test would assert that a function nobody calls returns what the platform told it, and would imply the app handles the disabled-notification case — which it does not. That is F5 in docs/coverage-read-findings.md, and it asks for a decision, not a test.

Gate

Full gate green. 561 → 563 JVM tests, 0 failures. No production code changed.

🤖 Generated with Claude Code

Closes #174. Stacked on #183. An **assertion** gap rather than a coverage one, which is exactly why it survived. JaCoCo is green on `build()`'s `if (indeterminate)` — `ProgressNotificationTest` drives it through a real worker — but that test reads the notification id and `EXTRA_PROGRESS` and nothing else. **Nothing had ever read the text.** | mutation | before | now | |---|---|---| | swap the two content texts | green | **red** | | replace the caller's title with a constant | green | **red** | What it costs to get wrong is small and permanent: a conversion four minutes in still saying "Preparing…", or one that has not started reporting yet claiming 0%. Neither is a crash, and nothing else here would have found it. ### Why nothing had constructed this class directly Mechanical, not an oversight: `build()` reaches `WorkManager.getInstance` for the Cancel action's `PendingIntent`, so the notification cannot be built without one. `installTestWorkManager` in `setUp` is the whole fixture — and the KDoc records the coupling so the next person does not rediscover it. ### `areEnabled()` is deliberately still untested It has no caller anywhere in `app/src/main`. A test would assert that a function nobody calls returns what the platform told it, and would imply the app handles the disabled-notification case — which it does not. That is **F5** in `docs/coverage-read-findings.md`, and it asks for a decision, not a test. ### Gate Full gate green. 561 → 563 JVM tests, 0 failures. No production code changed. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Sign in to join this conversation.