Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
0% found this document useful (0 votes)
48 views

Debugging React Tests: 1. Reducing The Number of Tests

This document provides tips for debugging React tests, including: 1. Reducing the number of tests run by using test.only or describe.only. 2. Inspecting the DOM using the debug function from react-testing-library. 3. Waiting for elements to appear or disappear using waitForElementToBeRemoved.

Uploaded by

Abraham Samuel
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
48 views

Debugging React Tests: 1. Reducing The Number of Tests

This document provides tips for debugging React tests, including: 1. Reducing the number of tests run by using test.only or describe.only. 2. Inspecting the DOM using the debug function from react-testing-library. 3. Waiting for elements to appear or disappear using waitForElementToBeRemoved.

Uploaded by

Abraham Samuel
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 1

Debugging React Tests

For a hands on debugging and reactoring session of a React test see this blog post!

1. Reducing the number of tests This takes a lot of the guesswork out of testing. It can
even help you debug production bugs since you can
Use test.only or describe.only to run a single test. If easily control and automate scenarios with tests.
you need to skip one or multiple tests you can use
xtest or xdescribe. 8. Setting breakpoints
2. Inspecting the DOM Breakpoints might disappear or jump to another
position when you (re)start the debugger. Simply set
The debug function returned by testing-library’s them again once your tests are running.
render can be used to inspect the rendered
component. 9. Re-running tests
3. Inspecting a single element You can run tests in watch mode again when you hit
“a” in the terminal. Or you use ⌘+S or Ctrl+S to save a
The debug function accepts an element as first test or application file.
parameter. This comes handy when the tested
component is too large and the output by debug in the 10. console.log and inline functions
console is cut off.
Use the || operator for chaining a console.log call with
The parameter can also be an array of elements. an inline function instead of adding curly brackets
around the function body.
4. Waiting for an element to disappear
onChange={e => console.log(e) || onChange(e)}
In some situations you need to wait until an element
like a loading spinner disappears. Then you can use 11. Investigating variables
testing-library’s asynchronous
waitForElementToBeRemoved function. Use your debugger’s variables panel to investigate any
variable or the application state at a certain point of
But in many cases you can simply wait until the desired code execution.
element appears. Then it might make more sense to
use the findBy* functions 12. Checking mocks
5. Don’t use click events on select When you’re not sure if a mock file is correctly
imported you can set a console.log statement in the
inputs
mock and real file below the imports.
The user flow of clicking on a select input’s option
Alternatively you can use breakpoints and step into
might trick you into using a click event. You need to
the functions.
use a change event instead as for any other input.

Also see the hint below. 13. Correct mocking


Remember: User modules need to be mocked
6. Separate library for user events
manually, mocks of npm packages will be used
If you need to simulate user events like typing inside automatically by Jest.
an input, double clicking, or tabbing you might need
the separate library user-event. 14. The within function
It also includes a function to pick an option from a testing-library has a within function. It comes handy
select input. when you need to check a specific place of an element
or a text when it appears multiple times in the tested
7. Use your editor’s debugger component.

Many editors or IDEs include a debugger. You can use


them to be step through the code execution of your
tests the same way you would use a debugger in the
browser.

You might also like