aglinxinyuan opened a new pull request, #7891:
URL: https://github.com/apache/texera/pull/7891
### What changes were proposed in this PR?
Both workspace templates go to **100% lines, branches and functions**. 37
tests → 53.
Measured from `frontend/` with `ng test --coverage
--coverage-reporters=lcovonly`, the same spec-file filter on both sides, and
`rm -rf coverage` between runs. lcov parsed with Codecov's model: `DA=0` is
missed, `DA>0` with some `BRDA` arms at 0 is partial, and partial counts
against the percentage.
| Template | Before | After |
|---|---|---|
| `result-exportation.component.html` | 60/67 = 89.6%, branches 9/18,
functions 4/8 | **67/67 = 100%**, branches **18/18**, functions **8/8** |
| `ui-udf-parameters.component.html` | 40/46 = 87.0%, branches 6/8,
functions **0/5** | **46/46 = 100%**, branches **8/8**, functions **5/5** |
+13 Codecov fully-covered lines, +11 branch arms, +9 functions.
**Worth being precise about where that 13 comes from:** the raw lcov
line-hit delta is only +5. The other 8 lines move because Codecov counts a line
with any unhit branch arm as missed. Both companion `.ts` files were already at
100% lines, branches and functions before and after, so nothing here is a `.ts`
gain.
The `ui-udf-parameters` function counter is the one I would point a reviewer
at: **zero of its five template functions were covered**, which an 87% line
figure hides entirely.
### An existing comment in the spec was wrong, and it was the blocker
`result-exportation.component.spec.ts` asserted in a comment that the
nz-autocomplete option bodies are unreachable — that the option content "only
enters the DOM once the autocomplete panel expands, which jsdom does not drive."
That is false. `NzAutocompleteTriggerDirective` declares a host `focusin`
listener running `handleFocus()` → `canOpen()` → `openPanel()`, so dispatching
`new Event("focusin")` on the search input and calling `detectChanges()`
attaches the panel. Verified by rendering it: two option nodes, and clicking
one fires the export.
Two mechanics that follow, both now in the spec:
- The options render into the **overlay container in `document.body`**, so
they are queried with `document.querySelectorAll`. `fixture.debugElement`
returns zero.
- The expected count is derived from the component's own filtered list, so a
stale overlay from a sibling test cannot make the assertion vacuous.
### Verification
30 mutations, **all 30 killed, no survivors.** Every mutant was re-derived
from scratch against the repaired specs, one at a time. This includes all 8
that the two adversarial reviewers reported as surviving the first draft.
Three mutants were **discarded as non-viable rather than counted**, and by
build evidence rather than argument:
- Two `[nzDescription]="…length || null"` variants are **type-invalid** —
`ng build` rejects them under `strictTemplates`. A mutant that only fails to
compile proves nothing, so they are not in the table either way.
- Swapping the `(keyup.enter)` and `(keyup.escape)` attributes wholesale,
event names included, is a pure attribute reorder with no semantic change.
### Corrections to the first draft
- `"survivors": []` was true of the table it ran, but that table was
defective: two of its fourteen rows were type-invalid mutants and its remaining
coverage was too narrow to support the bundle's claims.
- Two rows presented as proving a `|| null` fallback is load-bearing
actually prove only that nz-alert renders a description node; rewritten to say
that.
- The first draft flagged one test as soft, offering to fall back to 12
lines / 10 arms if a reviewer objected. That went the other way on measurement
— the test is fine and the fallback is not needed.
- A note claiming a placeholder branch was "already covered" was wrong; it
was not.
- A `droppedTargets` entry had correct arithmetic and the wrong conclusion.
### Deliberately not included
The "value editable, name and type locked" behaviour cannot be asserted
through a *rendered* formly-field: attaching a real `FormControl` before render
makes `FormlyField` throw `TypeError: Cannot destructure property 'updateOn' of
'field.modelOptions'`, because `fieldChanges()` assumes a fully built Formly
field. Standing up a full `FormlyModule.forRoot` form for that is out of scope,
and the behaviour is already covered at the unit level by three existing tests.
The rendered-row test asserts structure instead.
No production file is touched, and no production seam was needed — every one
of the 13 lines was reachable from a test-only change.
### Any related issues, documentation, discussions?
Closes #7890
### How was this PR tested?
```
npx ng test --watch=false
--include="**/result-exportation.component.spec.ts"
--include="**/ui-udf-parameters.component.spec.ts"
```
```
Test Files 2 passed (2)
Tests 57 passed (57)
```
jsdom prints two `AggregateError` blocks from `xhr-utils.js` during these
specs. Those are pre-existing — present identically in the untouched baseline
run. `frontend/junit.xml` and `frontend/coverage/` are regenerated by every run
and are not committed. `yarn format:ci` passes.
### Was this PR authored or co-authored using generative AI tooling?
Generated-by: Claude Code (Opus 5)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
