-
Notifications
You must be signed in to change notification settings - Fork 13.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: Drill to detail Modal tests #21148
Conversation
Codecov Report
@@ Coverage Diff @@
## master #21148 +/- ##
==========================================
+ Coverage 66.40% 66.51% +0.10%
==========================================
Files 1783 1783
Lines 68087 68087
Branches 7261 7261
==========================================
+ Hits 45215 45288 +73
+ Misses 21007 20931 -76
- Partials 1865 1868 +3
Flags with carried forward coverage won't be shown. Click here to find out more.
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
…e/drill-to-detail-modal-tests
Storybook has completed and can be viewed at |
}); | ||
}; | ||
const waitForRender = (overrides: Record<string, any> = {}) => | ||
waitFor(() => setup(overrides)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it really needed? Don't we always wait for render by default?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kgabryje in this component there are several async events that would fire warnings during the test runs if we don't wait for the component to be fully loaded. Hence the reason for this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh that's interesting. Does it mean that we should use this pattern in other components too? Maybe this should be a helper function in spec/helpers
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kgabryje not sure if it is worth creating a function that takes a component and wraps it in a waitFor while also taking eventual overrides but if you think it can help I am happy to create it in a separate PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, I think there are a lot of reusable helpers that we can create for these RTL tests. This could be an interesting project in order to enforce/suggest certain standards in writing RTL tests. CC @rusackas
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, approving this PR 👍 Do you think though that other tests would benefit from using this pattern? Should we use it to decrease the number of warnings?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can also use findBy
in many of these tests if you want to wait for the async operations. findBy is essentially the combination of getBy
and waitFor
. So this:
test('should render the title', async () => {
await waitForRender();
expect(
screen.getByText(`Drill to detail: ${chart.form_data.slice_name}`),
).toBeInTheDocument();
});
Could be written as:
test('should render the title', async () => {
setup();
expect(
await screen.findByText(`Drill to detail: ${chart.form_data.slice_name}`),
).toBeInTheDocument();
});
Either way, the important thing is to account for the async nature of the component as you did.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lgtm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
superset-frontend/src/dashboard/components/DrillDetailPane/TableControls.test.tsx
Outdated
Show resolved
Hide resolved
superset-frontend/src/dashboard/components/DrillDetailPane/TableControls.test.tsx
Outdated
Show resolved
Hide resolved
superset-frontend/src/dashboard/components/DrillDetailPane/TableControls.test.tsx
Outdated
Show resolved
Hide resolved
superset-frontend/src/dashboard/components/DrillDetailPane/TableControls.test.tsx
Outdated
Show resolved
Hide resolved
superset-frontend/src/dashboard/components/DrillDetailPane/TableControls.test.tsx
Outdated
Show resolved
Hide resolved
…leControls.test.tsx Co-authored-by: Michael S. Molina <70410625+michael-s-molina@users.noreply.github.com>
…leControls.test.tsx Co-authored-by: Michael S. Molina <70410625+michael-s-molina@users.noreply.github.com>
…leControls.test.tsx Co-authored-by: Michael S. Molina <70410625+michael-s-molina@users.noreply.github.com>
…leControls.test.tsx Co-authored-by: Michael S. Molina <70410625+michael-s-molina@users.noreply.github.com>
…leControls.test.tsx Co-authored-by: Michael S. Molina <70410625+michael-s-molina@users.noreply.github.com>
Storybook has completed and can be viewed at |
4 similar comments
Storybook has completed and can be viewed at |
Storybook has completed and can be viewed at |
Storybook has completed and can be viewed at |
Storybook has completed and can be viewed at |
…e/drill-to-detail-modal-tests
…m/apache/superset into chore/drill-to-detail-modal-tests
…e/drill-to-detail-modal-tests
SUMMARY
This PR adds RTL tests for the drill to detail modal originally implemented in this PR #20728
Related E2E tests: #21187
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
N.A.
TESTING INSTRUCTIONS
All the tests should succeed
ADDITIONAL INFORMATION