Question

119

React Testing Library - Avoid getBy?

rated 0 times [ 126] [ 7] / answers: 1 / hits: 11947 / 5 Years ago, thu, november 14, 2019, 12:00:00

When testing components with React Testing Library, I find myself starting with getBy*, and occasionally needing to replace it with queryBy* (for example if I need to check for the non-existence of an element). My tests end up with a mix of getBy and queryBy, and I've recently just been using queryBy for everything.

It got me thinking... is there ever a reason to use getBy?

Assertions like this fail as expected, without the need to throw an error:

expect(queryByText('Click me')).toBeInTheDocument();

expect(queryByLabel('Name').value).toBe('George')

What's the advantage of throwing an error if an element isn't found, and is there a reason not to use queryBy for all (synchronous) queries?

EDIT: It looks like queryBy is now only recommended for asserting that something is not in the document:

https://kentcdodds.com/blog/common-mistakes-with-react-testing-library#using-query-variants-for-anything-except-checking-for-non-existence

The article also recommends using screen.queryBy/screen.getBy rather than destructuring from render, which simplifies changing from one to another, since you no longer have to update the destructured function.

Answers

Only authorized users can answer the question. Please sign in first, or register a free account.

jaelynncherokeeg

Add To Favorites

Follow

Total Points: 697

Total Questions: 109

Total Answers: 104

Location: France

Member since Thu, Mar 18, 2021

3 Years ago

jaelynncherokeeg questions

1 NextJS load external image Amazon

Thu, May 27, 21, 00:00, 3 Years ago

1 Create an Array of Favorite fruits Object

Fri, Jan 24, 20, 00:00, 4 Years ago

1 How do I POST data to a .NET Core Web API using the fetch() javascript method

Thu, Sep 26, 19, 00:00, 5 Years ago

1 Yarn Link All Packages/Workspaces

Wed, Sep 18, 19, 00:00, 5 Years ago

1 yarn cannot build node-sass with node 12.1.0

Wed, May 15, 19, 00:00, 5 Years ago

View All

answered 5 Years ago jananauticat · Accepted Answer

As you've stated, the difference between getBy* and queryBy* is that getBy* throws an error if the element is not found and queryBy* does not. For me, if I'm expecting something to be there, I always use getBy* and only use queryBy* in scenarios where I'm asserting that something isn't there. If an element isn't present that I'm expecting to be, I want to know about it as early as possible in the test, which is wherever the getBy* call is made.

So I would say the advantage of throwing the error is that you always ensure your test failure will point to the root problem (not being able to find an element you expect to be there) as opposed to a side effect of that root problem (trying to use that element for something later in the test).

Example Test:

    const { getByTestId, queryByTestId } = render(getComponent());



    const textInput = queryByTestId(textInput);



    fireEvent.change(textInput, { target: { value: hello } });

    fireEvent.change(textInput, { target: { value: hi } });

Using queryByTestId, the test output is:

Unable to fire a change event - please provide a DOM element.



      23 |     const textInput = queryByTestId(textInput) as any;

      24 |

    > 25 |     fireEvent.change(textInput, { target: { value: hello } });

         |               ^

      26 |     fireEvent.change(textInput, { target: { value: hi } });

      27 |

So it does indicate that textInput wasn't found. If I change it to getByTestId, the output is

Unable to find an element by: [data-testid=textInput]



    <body>

      <div>

        <div>

          <button

            type=button

          >

            Show the Text Input!

          </button>

        </div>

      </div>

    </body>



      21 |     const { getByTestId, queryByTestId, rerender } = render(getComponent());

      22 |

    > 23 |     const textInput = getByTestId(textInput) as any;

         |                       ^

      24 |

      25 |     fireEvent.change(textInput, { target: { value: hello } });

      26 |     fireEvent.change(textInput, { target: { value: hi } });

So the getBy* error output has two advantages in my mind:

It points directly to the line that is the problem. It's not too hard to figure out that querying for the textInput is the problem in the first case. But it is a bit less direct.

It automatically prints what the DOM looks like when I use getBy*. This can be helpful when determining why something I'm looking for isn't present. Once the queryBy* test fails, that's likely one of the first steps I'm going to take anyways, so it's nice that it's just there automatically.

These marginal dev experience improvements are worth using the getBy* varieties as the default for me. Typically I'm only using getBy* in my tests and only using queryBy* when it's important to assert that something isn't present. It is certainly possible to just use queryBy* though and you are free to do so if you find the cost of using both outweighs the benefits.