aglinxinyuan commented on issue #7458:
URL: https://github.com/apache/texera/issues/7458#issuecomment-5249279104
Root cause found, and measured rather than inferred.
**The mechanism.** `TestBed.overrideComponent` makes Angular re-JIT the
component from its retained decorator metadata (`pendingComponents` →
`compileComponent` → `jitExpression`). The re-compiled template function
carries no source map back to the `.component.html`, so every binding still
executes and none of it is attributed. That is why the affected components show
a healthy `.ts` next to a `.html` at exactly zero — `agent-panel.component.ts`
is 98.5% with 0 of 133 lines missed while `agent-panel.component.html` is 0/49.
Nothing but attribution loss produces that pair.
**All eight zero-coverage templates are now accounted for**, by correlating
every one of the 98 `.html` files in the live Codecov report:
| Template | Lines | Cause |
|---|---:|---|
| `agent-panel` | 49 | overridden in its only rendering spec |
| `hub-workflow-detail` | 46 | same |
| `user-project` | 38 | same |
| `search` | 35 | same |
| `workspace` | 28 | same |
| `hub-search-result` | 25 | same |
| `ui-udf-parameters` | — | spec never uses TestBed (`new
UiUdfParametersComponent()`) |
| `collab-wrapper` | 67 | no spec (and #7351 deletes it) |
The two overridden specs whose templates *are* covered confirm the mechanism
from the other direction: `search-results.component.html` (75.8%) and
`operator-property-edit-frame.component.html` (68.2%) each have a **sibling**
spec that renders the real component un-overridden.
**The remedy works.** #7535 applies it to `hub-workflow-detail`:
| | Before | After |
|---|---|---|
| lines | 0/46 (0.0%) | **45/46 (97.8%)** |
| branches | — | 3/3 |
Three tests, and the existing 32 are untouched — the new block keeps its own
`TestBed` so those tests keep their mocked `WorkflowActionService` and the ten
assertions they make on it. Wholesale de-stubbing would mean rewriting those
ten, which is a worse trade than adding a render block.
**One thing that should change regardless of whether anyone picks up the
remaining five.** `frontend/.eslintrc.json` currently prescribes the pattern
that causes this, in three separate messages — the `NO_ERRORS_SCHEMA` rule and
both `overrideComponent` rules all tell authors to "stub it via
`overrideComponent({ remove: { imports: [Real] }, add: { imports: [Stub] }
})`". The `set: { template }` message is right that substituting a template
zeroes coverage, but the additive `remove`/`add` form it recommends instead
does the same thing, for the same reason. Accurate guidance would be: any
override zeroes the template's coverage, so prefer expanding the child's
service stubs so the real child can instantiate, and if a child genuinely
cannot be, add a sibling block that renders the real component.
Happy to send that eslintrc wording as its own small PR if that is wanted —
I kept it out of #7535 so the test change stays spec-only.
--
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]
