The GitHub Actions job "Required Checks" on texera.git/main has failed. Run started by GitHub user github-merge-queue[bot] (triggered by github-merge-queue[bot]).
Head commit for run: 8707f66b4536f3e287e91245239ec4c14f16f93a / Xinyuan Lin <[email protected]> test(frontend): cover the result-exportation and UI-UDF-parameters templates (#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) Report URL: https://github.com/apache/texera/actions/runs/32699583834 With regards, GitHub Actions via GitBox
