test(frontend): cover the computing-unit actions service and result panel - #8031
Open
aglinxinyuan wants to merge 1 commit into
Open
test(frontend): cover the computing-unit actions service and result panel#8031aglinxinyuan wants to merge 1 commit into
aglinxinyuan wants to merge 1 commit into
Conversation
…anel Both files reach 100% on lines, branches and functions: +6 fully-covered lines and +5 branch arms. The before figure on the template reproduces Codecov's published 94.3% exactly. Small, and worth it for the function counter: result-panel.component.html sat at FNF 7 / FNH 4 because its spec called handleEndDrag and handleStartDrag directly on the component, leaving the template's own bindings at FNDA:0 -- covered-looking and unexercised. Seventh time this campaign a file has had uncovered functions behind a healthy line figure. 18 mutations, all killed. The first pass claimed no survivors alongside "NO DEFECTS FOUND"; several of its own mutants survived it. Its arithmetic was also wrong -- two lines carry BRDA records but no DA record, because v8 attributes the DA for the whole modalService.confirm statement to the line above -- and one kill was credited to one test when it fails two. Neither file carries an unreachable partial, which is why this was taken at six lines when three sibling bundles the same size were dropped.
Contributor
Automated Reviewer SuggestionsBased on the
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #8031 +/- ##
============================================
+ Coverage 93.29% 93.31% +0.01%
Complexity 4678 4678
============================================
Files 1179 1179
Lines 47713 47713
Branches 5314 5314
============================================
+ Hits 44515 44521 +6
+ Misses 1732 1731 -1
+ Partials 1466 1461 -5
*This pull request uses carry forward flags. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changes were proposed in this PR?
Two small frontend files. Measured with the identical spec-file filter on both sides (two repeated
--includeglobs, never a test-name phrase),rm -rf coveragebetween runs, readingfrontend/coverage/gui/lcov.info.computing-unit-actions.service.tsresult-panel.component.html+6 fully-covered lines and +5 branch arms. The before figure on the template reproduces Codecov's published 94.3% exactly.
This is a small PR and I would rather say so than dress it up. What makes it worth having is the template's function counter.
The template's bindings were never entered
result-panel.component.htmlsat at FNF 7 / FNH 4 — three of its seven functions uncovered — because the existing spec calledhandleEndDrag(...)andhandleStartDrag()directly on the component. The bindings themselves stayed atFNDA:0: covered-looking, unexercised. Driving them through the rendered element is what closes them.That is the seventh time in this campaign a file has sat at a healthy line percentage with uncovered functions, and the second time the specific cause was a spec calling a handler directly instead of firing the binding.
Verification
18 mutations, all 18 killed.
The first draft claimed
survivors: []alongside "NO DEFECTS FOUND" and "nothing in the advertised gap was unreachable". Its own mutants were re-run against the bundle as shipped first, and several survived it; all now die.Two further corrections to that draft:
23/26 → 26/26. Lines 101 and 109 carryBRDArecords but noDArecord — v8 attributes theDAfor the wholemodalService.confirm({...})statement to line 99 — so on theunion(DA, BRDA)line set the correct figures are 26/29 → 29/29. Same delta, different denominator, and worth stating so the numbers reproduce.One vacuity worth naming, though it is not a survivor
The pre-existing test "renders the resize handles when the panel is docked" still passes a swap of the line-120
nzDirectionsarm on its own, because it never distinguishes the two directions. It is not a file-level survivor — the new tests kill that mutant — but the older test does not constrain what its name suggests.Deliberately not included
Nothing. Both files reach 100% on lines, branches and functions, and neither carries an unreachable partial — which is unusual at this point in the codebase and is why this bundle was taken at six lines when three sibling bundles at the same size were dropped.
No production file is touched. The worktree used a real yarn install rather than a
node_modulesjunction.Any related issues, documentation, discussions?
Closes #8030
How was this PR tested?
yarn format:cipasses.frontend/junit.xmlandfrontend/coverage/are regenerated by every run and are not committed.Was this PR authored or co-authored using generative AI tooling?
Generated-by: Claude Code (Opus 5)