Skip to content
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

Speed up tests #1763

Closed
2 tasks
Onokaev opened this issue May 30, 2022 · 1 comment · Fixed by #1837 or #1840
Closed
2 tasks

Speed up tests #1763

Onokaev opened this issue May 30, 2022 · 1 comment · Fixed by #1837 or #1840
Assignees
Labels
Epic type:infrastructure Core back-end work which includes quality work, code refactor, tests etc
Milestone

Comments

@Onokaev
Copy link
Contributor

Onokaev commented May 30, 2022

Describe the bug
We are currently not running tests for .tsx files because they are slow. The .tsx files recursively render components.

For instance, let's say component A has inner components B and C.

  • When testing component A, it will render component B and C. To fix this, we can mock component B and C so as to test component A in isolation.

However, we do not need to test all the tsx components individually. We can just test the root App component that renders all other components. From this single test, we can make all necessary assertions to ensure all components are rendered as expected.

This will be an extension of this effort: #1513

  • Remove .spec.tsx files and add assertions on App.spec.tsx
  • Add config changes for speeding up tests
@Onokaev Onokaev added the type:infrastructure Core back-end work which includes quality work, code refactor, tests etc label May 30, 2022
@Onokaev Onokaev self-assigned this May 30, 2022
@adhiambovivian adhiambovivian added this to the June-2022 milestone Jun 2, 2022
@Onokaev
Copy link
Contributor Author

Onokaev commented Jun 9, 2022

What are we testing? What the end user sees. For example, when you click on the Request headers tab, you'll see textboxes for the request headers. These tests confirm that what we expect the user to see are actually available.
We are testing the root component which renders all other components. All necessary assertions are made on this single test.

What these tests do not cover: The UI placement of components. As long as a component is rendered and what is expected on the UI is available, these tests will pass. We cannot catch positioning/placement/layout bugs with these tests. This is where we will use playwright.

  • We first test the whole page to ensure that all major sections are rendered like so:

image

  • We then test the functionality of the different sections. For instance, we are confirming that clicking the settings button renders a drop-down with the buttons 'change theme' and 'get a sandbox with sample data'

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Epic type:infrastructure Core back-end work which includes quality work, code refactor, tests etc
Projects
None yet
2 participants