Doubt about no-render-in-setup

[iiLearner]

Hi, I just updated eslint plugin and immediately it started complaining about having the render method in beforeEach method.

I came across this: https://github.com/testing-library/eslint-plugin-testing-library/blob/main/docs/rules/no-render-in-setup.md

but im a little confused, isnt this a bit redundant? since instead of rendering in beforeEach ill be rendering inside each test? or am i supposed to render in the first test only and then only then necessary rerender it?

[Belco90]

Hi! The idea behind this rule is to render the elements as close as possible to your tests, so you render them inside each test in the "arrange" step.

This is also a good way to encourage merging several assertions into the same test so you render once in a test and then assert as much as possible. This doesn't mean you must have a single test to check everything, but will help you trying to write less unit tests and more integration ones.

Additionally, this helps avoiding weird workarounds when you need a different fixture/scenario setup before rendering when the render is located in some before* hook.

You can find a bit more in the original issue: #207

Perhaps we should update the rule doc for clarifying this.

[iiLearner]

So, if im getting it right, is this a right example of how it should be done?

test('should be not emit "checkOut" prop if user click to add to cart button and "isCartLoading" prop is true', () => {
    props.isCartLoading = true;
    const { container } = render(renderComponent());
    expect(props.isCartLoading).toBeTruthy();
    const button = within(container).getByRole('button', { name: 'checkout-button' });
    userEvent.click(button);
    expect(props.addToCart).not.toHaveBeenCalled();
});
  
test('should be emit "share" prop if user click to share button', () => {
    const { container } = render(renderComponent());
    const button = within(container).getByRole('button', { name: 'share-button' });
    userEvent.click(button);
    expect(props.share).toHaveBeenCalled();
    expect(props.share).toHaveBeenCalledTimes(1);
});

I also have my doubt about the usage of wihin is that correct the way ive done it? basically trying to get button inside the current component.

[Belco90]

Assuming that props has been defined before those two tests and renderComponent is using it, that's the right approach indeed.

Regarding the within question, that's not the expected usage. You have the screen util which has all the queries available bounded to the body where the component was rendered. So your test should look like this:

import { screen } from '@testing-library/react'
// ...
test('should be not emit "checkOut" prop if user click to add to cart button and "isCartLoading" prop is true', () => {
    props.isCartLoading = true;
    render(renderComponent());
    expect(props.isCartLoading).toBeTruthy();
    const button = screen.getByRole('button', { name: 'checkout-button' });
    userEvent.click(button);
    expect(props.addToCart).not.toHaveBeenCalled();
});

The within util is meant to be used when you want to query something within a specific part of your component. For instance, imagine your component is rendering two forms with a "submit" for each. If you want the submit button from the second form, you can query the specific form, and then query the submit button within such form.

A couple of extra things to point out:

• I'd avoid extracting the rendering into a renderComponent util. I tend to do that in the past, but it's much clear to everyone to just inline the regular render with the component + props in each test.
• Avoid using toBeTruthy/toBeFalsy and assert for the actual expected value. You can run into false negatives with those two matchers.
• In the second test you are checking that the prop has been called with two matchers: toHaveBeenCalled() and then toHaveBeenCalledTimes(1). You can remove the former since the latter is more specific

Remember that the Testing Library org has a proper Discord channel where you can ask this sort of questions and the community will help you: https://discord.gg/testing-library