test(frontend): extend ComputingUnitSelectionComponent coverage with resource getters#6555
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 #6555 +/- ##
============================================
+ Coverage 72.54% 72.58% +0.04%
Complexity 3436 3436
============================================
Files 1145 1145
Lines 45129 45129
Branches 4975 4975
============================================
+ Hits 32738 32757 +19
+ Misses 10709 10686 -23
- Partials 1682 1686 +4
*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
This PR extends the existing frontend unit test coverage for ComputingUnitSelectionComponent by adding deterministic tests for previously-untested resource-display accessors/getters and a few small UI helper/handler methods. It aligns with the linked issue’s request to cover the “pure getter” surface area without changing production code.
Changes:
- Added unit tests for
getCurrentComputingUnit*resource accessors, derived display getters (limits/units/values/percentages/status), and status mapping helpers. - Added tests for
trackBy*,cancelEditingUnitName,openComputingUnitMetadataModal, andscrollToBottomOfPipModal(including an absent-element no-op case). - Imported
ComputingUnitMetadataComponentfor modal expectation matching in the new tests.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
90df8bb to
ff3d8e1
Compare
What changes were proposed in this PR?
Extends the existing
ComputingUnitSelectionComponentspec(
frontend/src/app/workspace/component/power-button/, codecov ~59%) to cover thepreviously-untested resource-display getters and a few small handlers. Follows
frontend/TESTING.mdand reuses the existingmakeComputingUnitfixture.Adds 13 tests:
getCurrentComputingUnit{Cpu,Memory}Usage,getCurrentComputingUnit{Cpu,Memory,Gpu}Limit,getCurrentComputingUnitJvmMemorySize,getCurrentSharedMemorySize: read the selected unit's raw values, and return"NaN"for every accessor when nothing is selected.getCpuLimit/getMemoryLimit(numbers),getGpuLimit/getJvmMemorySize/getSharedMemorySize,getCpuLimitUnit/getMemoryLimitUnit/getCpuUnit/getMemoryUnit;getCpuValue/getMemoryValue/getCpuPercentage/getMemoryPercentagereturn 0 when metrics are unavailable;getCpuStatus/getMemoryStatusmap to"success";getBadgeColorandgetUnitStatusTooltipmap status → color/tooltip.
trackByCuid/trackByIndexidentity,cancelEditingUnitNamestate reset,
openComputingUnitMetadataModalopens the metadata modal with theunit as
nzData, andscrollToBottomOfPipModalscrolls the deferred pip-logelement (and is a safe no-op when it is absent).
No production code was changed.
Any related issues, documentation, discussions?
Closes #6551
How was this PR tested?
Extended Vitest spec, run locally in
frontend/(whole file green, run 4× toconfirm determinism; failure path verified by breaking an assertion). To stay
deterministic,
scrollToBottomOfPipModalis driven with fake timers and astubbed
document.getElementById(a plain stand-in object, restored after eachtest) rather than relying on jsdom layout.
Was this PR authored or co-authored using generative AI tooling?
Generated-by: Claude Code (Opus 4.8 [1M context])