dashboard
dashboard copied to clipboard
Proposal for unit test guideline
What this PR does / why we need it
Here are some of points / guidelines regarding unit testing. Feel free to share your thoughts and suggest more points.
Which issue(s) this PR fixes
Release note
NONE
Codecov Report
Merging #4428 (9eef259) into main (a8fd157) will increase coverage by
0.22%
. The diff coverage isn/a
.
@@ Coverage Diff @@
## main #4428 +/- ##
==========================================
+ Coverage 50.51% 50.73% +0.22%
==========================================
Files 326 339 +13
Lines 11953 12451 +498
Branches 1302 1334 +32
==========================================
+ Hits 6038 6317 +279
- Misses 5913 6132 +219
Partials 2 2
Impacted Files | Coverage Δ | |
---|---|---|
...pp/dynamic/enterprise/metering/service/metering.ts | 10.52% <0.00%> (-22.81%) |
:arrow_down: |
src/app/shared/entity/settings.ts | 84.61% <0.00%> (-6.09%) |
:arrow_down: |
src/app/core/services/wizard/presets.ts | 27.39% <0.00%> (-0.97%) |
:arrow_down: |
...cluster/constraints/violation-details/component.ts | 92.30% <0.00%> (-0.29%) |
:arrow_down: |
...e/metering/schedule-config/add-dialog/component.ts | 62.50% <0.00%> (ø) |
|
.../metering/schedule-config/report-list/component.ts | 72.28% <0.00%> (ø) |
|
src/test/data/metering.ts | 100.00% <0.00%> (ø) |
|
src/test/services/metering-mock.ts | 100.00% <0.00%> (ø) |
|
src/app/core/services/wizard/provider/kubevirt.ts | 20.00% <0.00%> (ø) |
|
src/app/dynamic/enterprise/metering/component.ts | 78.57% <0.00%> (ø) |
|
... and 15 more |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update a8fd157...9eef259. Read the comment docs.
/lgtm /approve /hold
@floreks @KhizerRehan @ahmadhamzh do you want to add anything?
LGTM label has been added.
FYI, I posted those at the time of PR but somehow it was in PENDING state :)
Point: If a component is expected to react on events, try to cover that in tests.
I will like to know thoughts about how you are doing testing for components that have child component and nested child components?
Any reference component to test such events?
"If a component is expected to react on events"
- How to handle async API calls?
- How to handle async API calls which are interconnected like based on previous response perform next functionality?
While testing components you should focus on a component's API (e.g. props or triggering/triggered events). If a component has child components, those have their own APIs and we should not try to test them while testing the parent. Not being able to figure out the API for a tested component may mean that the component requires some refactoring.
Testing async API calls is preferred to be handled in E2E tests. In the component/unit tests we can still check how components behave based on some mocked data or see if async functions were invoked based on some component's logic.
For some more advanced flows, like the one mentioned in the last question, I strongly suggest considering E2E testing.
Unfortunately, I don't know if we have some good examples for my ideas in the Dashboard's codebase. Have in mind that I haven't worked much with the Dashboard, so maybe someone else will be able to point you to good examples.
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: ahmedwaleedmalik, maciaszczykm, pkprzekwas
The full list of commands accepted by this bot can be found here.
The pull request process is described here
- ~~OWNERS~~ [ahmedwaleedmalik,pkprzekwas]
Approvers can indicate their approval by writing /approve
in a comment
Approvers can cancel approval by writing /approve cancel
in a comment
/unhold