aglinxinyuan opened a new pull request, #8336:
URL: https://github.com/apache/texera/pull/8336
### What changes were proposed in this PR?
Four existing frontend specs extended. **+10 fully-covered lines and +7
branch arms.**
| File | Codecov | Branch arms |
|---|---|---|
| `user.service.ts` | 62/66 → **66/66** | 19/21 → **21/21** |
| `browse-section.component.ts` | 28/32 → 31/32 | 22/25 → 24/25 |
| `resource-registry.service.ts` | 18/20 → **20/20** | 16/17 → **17/17** |
| `email-request-modal.component.html` | 14/15 → **15/15** | 4/6 → **6/6** |
Three of the four reach 100%. The plain line-hit metric moves only **+4**
against Codecov's +10, because six of the gained lines were already executing
and flip solely by completing a branch arm — the two numbers are not
interchangeable and both are given.
Not-fully-covered across the bundle goes 13 → 3, and all three of those are
deliberately declined (below).
### The reviewer revised my own claim down
The build reported +11 lines and +8 arms. Independent re-measurement puts it
at **+10 and +7**: `browse-section.component.ts` gains 3 lines and 2 arms, not
4 and 3. Line 96 remains partial. The lower figure is the one in the table.
### Two files were in scope and contribute nothing
- **`user-dataset-version-creator.component.ts` was dropped entirely.** Its
only missed line is `get formControlNames()`, and a repo-wide grep across `.ts`
and `.html` returns exactly one hit — its own declaration. **Zero call sites,
zero template bindings.** A test there would be a pure count-raiser, so the
getter is flagged as a dead-code removal candidate instead.
- `browse-section.component.html` (24/24) and
`email-request-modal.component.ts` (8/9) were measured both ways and are
unchanged.
### Deliberately not included
`browse-section.component.ts:96` stays partial, and
`email-request-modal.component.ts:67` is declined.
One survivor is reported rather than chased: mutating `user.service.ts:108`
from `handleAccessToken(accessToken ?? "")` to a conditional survives the
suite. That mutant is character-for-character the shape `register()` already
uses for the same `string | null` payload — it is arguably the *fix*, not a
regression, so no test was written to pin the current form.
`user.service.ts:184` (`this.cache.delete(avatarUrl)`) is covered but **not
independently pinned**: the code immediately falls through to a `map` that
overwrites the entry either way, so no mutation isolates it. It rides along
with lines 180 and 183 in one test, and that is stated rather than presented as
a kill.
### Verification
Measured with the **full 209-file suite in one command** — no name filter
and no `--include` at all — so there is no filter-attribution risk, with
`coverage/` deleted before each run. The baseline was rebuilt by writing the
`HEAD` versions of the four specs into place from a scratch extraction (never
`git checkout`), running, then restoring from a hash-verified snapshot. Figures
parsed straight from `coverage/gui/lcov.info`.
Seven reviewer findings, all repaired — including one test that was
**deleted** rather than kept, because it duplicated an existing assertion.
`browse-section.component.ts:114` needed a white-box assertion or the test
would have been vacuous: `getCoverImage()`'s `|| this.defaultBackground` makes
the guarded and unguarded paths observably identical through the public API, so
the test asserts on the private `coverImageUrls` map. That is unusual and is
called out here rather than left for a reader to find.
`yarn format:ci` passes. `frontend/junit.xml` is regenerated by every run,
is not gitignored, and is not committed. No production file is touched.
### Any related issues, documentation, discussions?
Closes #8334
### How was this PR tested?
```
npx ng test --watch=false --include="**/user.service.spec.ts"
--include="**/browse-section.component.spec.ts"
--include="**/resource-registry.service.spec.ts"
--include="**/email-request-modal.component.spec.ts"
```
```
Test Files 4 passed (4)
```
Re-run after rebasing onto current `main`.
### 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]
