aglinxinyuan opened a new pull request, #7972:
URL: https://github.com/apache/texera/pull/7972
### What changes were proposed in this PR?
`result-table-frame.component.spec.ts` goes from 41 tests to 46, closing the
last reachable gap in the component.
Measured from raw lcov (v8 via vitest), identical include glob on both
sides, `rm -rf coverage junit.xml` between runs. The before figure came from
restoring the spec with `git show HEAD:<spec>` — a single exact path, never a
directory checkout.
| Counter | Before | After |
|---|---|---|
| Lines hit | 184/185 = 99.46% | **185/185 = 100%** |
| Codecov's metric (fully covered) | 180/185 = 97.30% | **184/185 = 99.46%**
|
| Branch arms | 92/96 | **95/96** |
| Functions | 37/37 | 37/37 |
**+4 fully-covered lines and +3 branch arms — and this is plainly a small
PR.** Three short tests, ~40 spec lines. I would rather say that than dress it
up: 184/185 is this file's permanent ceiling under a test-only change.
Functions were already 37/37 with zero `FNDA:0` entries in both runs. Worth
checking rather than assuming, because three times in this campaign a file sat
at high line coverage with functions uncovered.
### What the new tests actually pin
One of them closes a real hole rather than a counter: an existing test's
*name* claimed it exercised the empty-result guard, while its body actually
exercised the `operatorId` guard. The two are now separated.
Another covers a genuinely reachable path that the type signature denies:
`IcebergDocument.getTableStatistics` emits **ISO date strings** for `Timestamp`
column min/max, contradicting the frontend's `Record<string, Record<string,
number>>`. Reaching it needs two `as unknown as number` casts, which the test
carries a comment explaining — otherwise a reviewer would reasonably read it as
a coverage hack.
### Verification
16 mutations, **14 killed, 2 survivors**, both stated rather than papered
over.
- **`BRDA:250,20,1` is structurally dead.** The `: currentStr` arm of
`previous !== undefined ? previous.toFixed(2) : currentStr` sits inside `typeof
current === "number" && typeof previous === "number"`, so `previous` is
provably not undefined. Closing it would need a production edit (deleting the
vacuous guard), which the test-only constraint forbids. This is why the ceiling
is 184/185.
- **A single-sided `previous.toLocaleString()` → `String(previous)` at line
253 survives, and is left unkilled on purpose.** It is observable only when the
*same* column's stat is non-numeric in one snapshot and a number ≥ 1000 in the
other — a mid-run stat type flip. Pinning that would cement a shape the backend
does not produce.
Five claims from the first draft were corrected, including a test title that
claimed to observe `toLocaleString` for string payloads (it cannot —
`String#toLocaleString` returns the same string), and a "there is no other gap
for anyone to re-hunt" conclusion drawn from the absence of zero-count lcov
entries, which is a category error: a fully-hit file can still be entirely
unpinned.
### Reported, not pinned
An empty fetched page returns at the line-424 guard **before**
`isLoadingResult = false` at line 428, so the `nz-table`'s bound spinner never
clears for an operator that produced zero rows. The test deliberately omits
that assertion so this PR does not cement it; it deserves its own issue.
No production file is touched, and the worktree's `node_modules` is a real
install rather than a junction.
### Any related issues, documentation, discussions?
Closes #7971
### How was this PR tested?
```
npx ng test --watch=false --include="**/result-table-frame.component.spec.ts"
```
```
Test Files 1 passed (1)
Tests 46 passed (46)
```
`yarn format:ci` passes. `frontend/junit.xml` and `frontend/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)
--
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]
