test(frontend): render the hub workflow detail with its real children - #7535
Merged
Merged
Conversation
hub-workflow-detail.component.html reported 0 of 46 lines covered while its own .ts sat at 98%, which is not an undertested template - it is the attribution loss recorded in apache#7458. The existing spec stubs the three child components out through TestBed.overrideComponent, and any override makes Angular re-JIT the component from its retained decorator metadata; the re-compiled template has no source map back to the .html, so every binding still executes and none is counted. Adds a describe block that renders the component with its real children, which restores attribution: the template goes from 0/46 to 45/46 lines and 3/3 branches. It keeps its own TestBed so the 32 tests above retain their mocked WorkflowActionService and the ten assertions they make on it; the real service is needed here only because the real editor injects DynamicSchemaService, which reads the graph's operator streams. No production file is touched.
Contributor
Automated Reviewer SuggestionsBased on the
|
Open
6 tasks
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #7535 +/- ##
============================================
+ Coverage 87.42% 87.52% +0.10%
Complexity 4253 4253
============================================
Files 1176 1176
Lines 46986 46986
Branches 5245 5245
============================================
+ Hits 41077 41126 +49
+ Misses 4178 4131 -47
+ Partials 1731 1729 -2
*This pull request uses carry forward flags. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
This was referenced Aug 13, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changes were proposed in this PR?
hub-workflow-detail.component.htmlreported 0 of 46 lines while its own.tssat at 98% — theattribution loss from #7458, not a testing gap. The spec stubs its three children out through
TestBed.overrideComponent, and any override re-JITs the component from its decorator metadata; there-compiled template has no source map back to the
.html, so the bindings execute uncounted.Adds a
describeblock that renders the component with its real children. That restoresattribution:
Three tests: the real editor and mini-map resolving rather than the stub selectors, and the
*ngIf="isHub"back button appearing and not appearing. It keeps its ownTestBedso the 32 testsabove retain their mocked
WorkflowActionServiceand the ten assertions they make on it — the realservice is needed here only because the real editor injects
DynamicSchemaService, which reads thegraph's operator streams.
Verification
Both
*ngIfmutations were applied to the template and reverted (production diff empty):*ngIf="true")*ngIf="false")Two assertions in the first test are honestly guards, not behaviour pins: renaming the child
elements only breaks the template build rather than producing a clean behavioural failure, so they
are there to stop the override creeping back in, and the coverage measurement above is their real
evidence. Saying so rather than listing them as killed mutations.
One assertion was dropped during review of my own work: the clone button's
[disabled]="!isLogin || !isHub || !isActivatedUser"does not reflect to the DOMdisabledproperty under this fixture (it stays
falsewithisHub === false), so asserting on it would havebeen either vacuous or wrong. The back button discriminates cleanly and is what the tests use.
No production file is touched.
Any related issues, documentation, discussions?
Closes #7534
How was this PR tested?
3 new on top of the existing 32.
yarn format:cipasses.Was this PR authored or co-authored using generative AI tooling?
Generated-by: Claude Code (Opus 5)