🤖Assessing Coverage When Branch Coverage Is Low

I’m using the test-coverage assessment guidance because you asked for behavioral coverage, not just a percentage. I’ll examine direct and indirect tests, then use targeted coverage to identify any meaningful unprotected branches.

## Assessment: insufficiently covered

Targeted coverage for load-events.ts (src/app/app-shell/load-events.ts:22):

| Metric | Result |
|---|---:|
| Statements | 100% |
| Lines | 100% |
| Functions | 100% |
| Branches | 73.52% (25/34) |

The direct tests in events.spec.ts (tests/app/app-shell/events.spec.ts:34) cover normal request/success/failure flows, URL vs payload hotel selection, Forecast vs Standards loading, and all app-version formatting cases.

Meaningful missing branches:

- Failure-message normalization (src/app/app-shell/load-events.ts:71): Error, string, and missing/empty-message fallbacks are untested.
- Load requests with hotelChanged: true (src/app/app-shell/load-events.ts:99): neither Forecast nor non-Forecast request is verified to emit a success event carrying true.

I did not run mutation testing because relevant branch coverage is not yet high enough; it would mostly report noise from these untested paths.

I’ll add characterization coverage for the currently untested, observable handler paths: error-message fallback and hotelChanged request propagation. I’m using the Reffects, test-writing, test-data-builder, and coverage-assessment guidance because this adds direct event-handler tests and validates their branch protection.

Characterization scope is now clear: existing tests cover ordinary object failures and hotelChanged: false; I’ll add reachable cases for Error/fallback message normalization and hotelChanged: true for both Forecast and non-Forecast request paths. null is excluded by the handler’s declared payload type, so I won’t distort the public boundary to test it.

The added tests characterize the observable effects—not the helper internals—across both unprotected decision families.

Targeted coverage is now 100% for statements, lines, functions, and branches (19/19, 34/34). The coverage gate is clear, so I’m running the required narrow mutation check against load-events.ts with only its direct spec.

Coverage is now 100% for load-events.ts (src/app/app-shell/load-events.ts:1): 19/19 statements, 34/34 branches, 8/8 functions, and 19/19 lines.

Added characterization cases in events.spec.ts (tests/app/app-shell/events.spec.ts:92) for:

- hotelChanged: true on Forecast and Standards requests.
- Error, empty Error, object without a message, string error, and missing error fallback behavior.

Validation passed: focused tests, targeted coverage, lint, full typecheck/test suite (1,128 tests), and production build.

The targeted mutation run’s dry run passed but the environment terminated it before a final score. The combined agent-validate command likewise hit the 30-second tool limit; its constituent lint, test, and build commands all passed separately.

Targeted branch coverage is already 100%, so the mutation gate is appropriate. I’ll run Stryker only for load-events.ts with its direct spec and poll the active process until it exits.
The mutation run is active: it generated 84 mutants and its initial test run passed. I’m continuing to wait for Stryker’s final report.

Targeted mutation testing completed successfully.

- Scope: src/app/app-shell/load-events.ts
- Tests: tests/app/app-shell/events.spec.ts
- Result: 92.59% mutation score — 50 killed, 4 survived, 0 timed out, 30 errored.

The survivors are explainable:

- Optional chaining on error?.message: equivalent under the declared error type, which excludes null.
- Three mutations of page === "forecast": both branches in pageShellRequestEvents currently return equivalent event shapes, making that condition redundant from an observable-behavior perspective.

Report: reports/mutation/mutation.html (ignored generated output).

Yes. Given ShellError excludes null, the optional chain is redundant:

error.message || hotelContextError

The guard is only needed if null can reach this handler at runtime.

I’ll remove the redundant optional chain while preserving the handler’s typed contract (ShellError excludes null). I’m applying the Reffects and coverage guidance because this changes an event handler whose behavior is protected by its direct tests.

The focused test and coverage pass, retaining 100% branch coverage. I’ll rerun the same targeted mutation scope to confirm the redundant mutation is gone.

The simplification removed that survivor: mutation score improved from 92.59% to 94.34%, with only three survivors remaining from duplicated pageShellRequestEvents branches. I’ll now format and run the completion checks for the production-code change.

Simplified load-events.ts (src/app/app-shell/load-events.ts:74) to use error.message.

Validation passed:

- 100% targeted coverage
- Targeted mutation score: 94.34% (the optional-chaining survivor is gone)
- npm run agent-validate: lint, 1,128 tests, and production build all pass.

pageShellRequestEvents has this shape:

return page === "forecast"
  ? { successEvent: ..., errorEvent: ... }
  : { successEvent: ..., errorEvent: ... };

But both branches construct the same events. So changing the condition to always true, always false, or !== does not change output—hence the mutations survive.

It can be simplified to one returned object without the page === "forecast" condition.

Most likely it’s leftover scaffolding: the author expected Forecast and non-Forecast pages to eventually need different shell-load events, wrote the branching structure early, but never introduced the divergence.

There’s no current behavior justified by the condition—the tests and mutation results confirm both paths are identical. It may have been intended for things like:

- Forecast carrying a different success/error event or extra payload.
- Standards/Roles skipping or altering a shell-load step.
- A future page-specific request configuration.

Today it is dead conditional structure. Simplifying it is safe as long as there’s no near-term requirement to split those flows.

I’ll remove the duplicate Forecast/non-Forecast branches while preserving the shared success and error event contract. The existing direct tests cover both page categories, and I’ll rerun coverage and mutation testing afterward.

The refactor preserves all 24 focused tests and leaves the module at 100% targeted branch coverage. I’m running the final narrow mutation check now.

The duplicate branch is gone; the targeted mutation run now reports 100% mutation score (50 killed, no survivors or timeouts). I’ll finish with formatting and the full frontend gate.

Simplified pageShellRequestEvents to one shared return object in load-events.ts (src/app/app-shell/load-events.ts:96).

Results:

- Targeted coverage: 100%
- Targeted mutation score: 100% (50 killed, 0 survived)
- Lint and full 1,128-test suite passed; production build passed separately after the combined gate hit the tool time limit during build output.