test(frontend): render the hub search result with its real children - #7661
Merged
aglinxinyuan merged 1 commit intoAug 15, 2026
Merged
Conversation
hub-search-result.component.html reported 0 of 23 lines, 0 of 8 branches and 0 of 3 functions covered, behind a 17-test spec. That is the attribution loss recorded in apache#7458: the spec swaps its four children for same-selector stubs via TestBed.overrideComponent, and any override re-JITs the component from its decorator metadata, so the recompiled template has no source map back to the .html. Adds a describe block that renders the component with its real children, taking the template to 23/23 lines, 8/8 branches and 3/3 functions. It keeps its own TestBed, so the existing suite and its stubs are untouched. The view-toggle helper reads each button's nzType by name rather than testing for ant-btn-primary. A boolean read pins only the true leg, so changing the false leg from 'default' to 'dashed' or 'link' shipped green until this was corrected. No production file is touched.
Contributor
Automated Reviewer SuggestionsBased on the
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #7661 +/- ##
============================================
+ Coverage 90.14% 90.19% +0.05%
Complexity 4417 4417
============================================
Files 1174 1174
Lines 46964 46964
Branches 5262 5262
============================================
+ Hits 42334 42360 +26
+ Misses 2876 2850 -26
Partials 1754 1754
*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:
|
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.
Suppressed comments (2)
frontend/src/app/hub/component/hub-search-result/hub-search-result.component.spec.ts:515
- The new suite’s
afterEachremoves the.cdk-overlay-containerelement from the document. Most frontend specs instead clear its contents (e.g.,dashboard/component/user/search-results/search-results.component.spec.ts:98,dashboard/component/user/user-project/user-project.component.spec.ts:116), which avoids breaking later tests that expect the container element to exist. Consider clearinginnerHTMLinstead of removing the node, and similarly avoid clearing all oflocalStoragehere (remove onlyVIEW_MODE_STORAGE_KEY).
afterEach(() => {
fixture?.destroy();
localStorage.clear();
document.querySelectorAll(".cdk-overlay-container").forEach(el => el.remove());
});
frontend/src/app/hub/component/hub-search-result/hub-search-result.component.spec.ts:468
render()clears all oflocalStorage, which can interfere with unrelated specs running in the same Karma session. In other frontend specs, the common pattern is to clean up only the key under test (e.g.,user-dataset.component.spec.ts:337useslocalStorage.removeItem(VIEW_MODE_KEY)). Consider removing justVIEW_MODE_STORAGE_KEYhere instead ofclear().
This issue also appears on line 511 of the same file.
TestBed.resetTestingModule();
localStorage.clear();
if (storedViewMode !== undefined) {
localStorage.setItem(VIEW_MODE_STORAGE_KEY, storedViewMode);
}
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-search-result.component.htmlreported 0 of 23 lines, 0 of 8 branches and 0 of 3 functions covered, behind a 17-test spec. That is the attribution loss from #7458, not an untested template: the spec swaps its four children for same-selector stubs viaTestBed.overrideComponent, and any override re-JITs the component from its decorator metadata, leaving the recompiled template with no source map back to the.html.Adds a
describeblock that renders the component with its real children:The block keeps its own
TestBed, so the 17 existing tests keep their stubs and assertions untouched. Same remedy as merged PRs #7535, #7627 and #7629 — this is the last of the six templates #7458 identified, barworkspaceand theuser-projectone that the project-feature removal deletes.Covered: the real children resolving rather than the stub selectors, the dataset-only view toggle and its absence for workflows, which toggle button is highlighted, the sort options shown and hidden per search type, the sort handler's two halves, the card template and its
viewModeguard, and the three inputs handed to the results list.Verification
23 mutations applied and reverted, production diff empty each time.
Two then turned out to survive, and the cause is worth recording. The view-toggle helper read each button as
classList.contains("ant-btn-primary"), which pins a ternary's true leg only — so changing the false leg from'default'to'dashed'or'link'shipped green. The build's own mutations replaced the whole ternary with a constant, which flips the primary leg and dies, which is exactly why the gap was missed.The helper now reads the type by name, matched against the nzType names rather than any
ant-btn-*class, since the buttons also carryant-btn-icon-only— my first attempt at the fix picked that modifier up and failed loudly, which is how I found it.All three are now red, each on the intended test rather than merely somewhere in the suite:
dashedlinkDeliberately not included
A static
nzTheme="outline"attribute carries no lcov line and is not asserted.No production file is touched.
Any related issues, documentation, discussions?
Closes #7660
How was this PR tested?
10 new on top of the existing 17. Coverage re-measured by reverting the spec, running with
--coverage, and restoring.yarn format:cipasses.Was this PR authored or co-authored using generative AI tooling?
Generated-by: Claude Code (Opus 5)