test(frontend): cover the console frame's controls and the preset guards - #7733
Conversation
Automated Reviewer SuggestionsBased on the
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #7733 +/- ##
============================================
+ Coverage 90.97% 91.05% +0.08%
Complexity 4458 4458
============================================
Files 1174 1174
Lines 47139 47139
Branches 5284 5284
============================================
+ Hits 42884 42924 +40
+ Misses 2569 2541 -28
+ Partials 1686 1674 -12
*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:
|
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.
Suppressed comments (5)
frontend/src/app/workspace/component/result-panel/console-frame/console-frame.component.spec.ts:451
- Querying the open
nz-selectoptions from the globaldocumentis brittle (it can pick up options from other overlays). Scope the query to the TestBed's CDKOverlayContainerinstead.
const options = Array.from(document.querySelectorAll("nz-option-item"));
frontend/src/app/workspace/service/preset/preset.service.spec.ts:207
- Same as the preceding test: the observable behavior being asserted is the thrown error, not that the preset isn't written. Consider renaming to match what the test verifies.
it("refuses to save with a 'warning' severity when no message is supplied", () => {
frontend/src/app/workspace/component/result-panel/console-frame/console-frame.component.spec.ts:544
- Like the nz-select test above, querying dropdown menu items/switches from the global
documentcan become flaky if any other overlay is present. Scope these queries to the CDKOverlayContainerfor this TestBed.
const menuItems = Array.from(document.querySelectorAll("li[nz-menu-item]"));
expect(menuItems.map(item => item.textContent?.trim())).toEqual(["Show Timestamp", "Show Source"]);
const switches = Array.from(document.querySelectorAll("nz-switch button.ant-switch")) as HTMLElement[];
expect(switches.length).toBe(2);
frontend/src/app/workspace/component/result-panel/console-frame/console-frame.component.spec.ts:22
- The new overlay-driven tests query elements via
document.querySelectorAll(...). In this repo, overlay assertions are typically scoped via CDKOverlayContainerso tests don't accidentally match elements from other overlays/specs. ImportOverlayContainerso the tests can inject and query it.
This issue also appears in the following locations of the same file:
- line 451
- line 541
import { ComponentFixture, TestBed, fakeAsync, flush, tick } from "@angular/core/testing";
import { By } from "@angular/platform-browser";
import { Subject } from "rxjs";
frontend/src/app/workspace/service/preset/preset.service.spec.ts:198
- This test name says it "refuses to save", but
savePresetsperforms the persistence/stream side effects before throwing whendisplayMessageis undefined. Renaming the test to describe the actual behavior (throwing) will keep intent clear even ifsavePresetsis refactored later.
This issue also appears on line 207 of the same file.
it("refuses to save with an 'info' severity when no message is supplied", () => {
What changes were proposed in this PR?
Two small frontend targets. The headline is the console frame template, whose line percentage hid the real gap:
console-frame.component.htmlconsole-frame.component.tspreset.service.ts7 tests added. Covered:
ngOnChangesadopting a new operator id, the empty-list fallback, typing into the command box through a realinputevent and submitting, narrowing the send by picking a worker in thenz-selectoverlay, the settings dropdown's two toggles, and twopreset.servicevalidation guards.This is 8 lines by line-count. What earns it is the branch and function coverage on the template — every interactive control in the console frame was previously unexercised — and that all 8 mutations die.
Not an #7458 case, and worth saying so
The obvious guess for a dark template here is the
TestBed.overrideComponentattribution loss behind merged PRs #7535, #7627, #7629, #7661, #7681 and #7727. It is not: the existing spec usesimports: [ConsoleFrameComponent, ...]with no override, and the coverage map shows bindings executing counted (the*ngForstatement has 124 hits). So this extends the existing TestBed rather than appending a separate one — the opposite call from #7727, for a checkable reason.Verification
8 mutations, 8 killed, no survivors, each applied one at a time with the anchor asserted unique, reverted and
git diff-checked between every run. All failures are assertion failures, never compile errors.[(ngModel)]="showTimestamp"and"showSource"[(ngModel)]="targetWorker"-> one-way[(ngModel)]="command"-> one-waycurrentValueandpreviousValuengOnChangesadopts the newly bound operator id|| []fallback"error"and"info"switch bodiespush(replacementPreset)->push(originalPreset)"warning"a default toast instead of throwingThe first one is the reason the fixture is not degenerate: the kill lands on the independence assertion (timestamp off, source still on). Turning both toggles off at once would have survived the exchange.
One mechanical note worth recording: the settings dropdown's menu is projected into a CDK overlay wired in
ngAfterViewInitbehind anauditTime(150), so its fixture must be created insidefakeAsync. Created in a plainbeforeEach, the timers escapetick(), the overlay never attaches, and the switch count is 0 — a test written against that state would pass while asserting nothing.Deliberately not included, with evidence
updatePreset(lines 184-190) is dead and buggy, so no test was written for it. It has zero call sites repo-wide outside its own spec. AndindexOf(presets, originalPreset)is lodash reference-equality against a freshlyJSON.parsed array, so it always returns-1:splice(-1, 1)deletes the wrong preset andpresets[-1] = ...is a silent no-op thatJSON.stringifydrops. Its siblingupdateOrCreatePresetcarries the comment "presets are freshly JSON-parsed, so reference-based indexOf would miss" and usesfindIndex(isEqual)— the fix was applied there and not here. Any test would cement the bug.console-frame.component.htmllines 54 and 59 are structurally unreachable:#checkedTemplateand#unCheckedTemplateare each declared twice (36/41 and 53/58), and bothnz-switches resolve to the first pair. The coverage map proves it — statements at 37/42 have 46 hits (2 switches x 23 fixtures) while 54/59 have 0..tsbranch arms are guard-guaranteed:renderConsole()'sif (this.operatorId)already forces the ternary's true leg, and#consoleListis unconditional in the template so its@ViewChildis always set in a rendered fixture.A third, weaker observation, reported and not pinned:
ngOnChangesdoesthis.operatorId = changes.operatorId?.currentValue, so anngOnChangesfired by a change toconsoleInputEnabledalone would wipeoperatorIdtoundefinedand silently disable the debug console.ResultPanelComponentalways sets both inputs together, so it is latent rather than triggered today; the new test pins only the normal path.No production file is touched.
Any related issues, documentation, discussions?
Closes #7732
How was this PR tested?
86 tests green in the two target specs; 174 green including the consumer specs
result-panel.component.spec.tsandpreset-wrapper.component.spec.ts, checked for CDK-overlay leakage across specs.yarn format:cipasses.Was this PR authored or co-authored using generative AI tooling?
Generated-by: Claude Code (Opus 5)