v5.5.1 introduces act-type warning in tests

Hey! I just wanted to respectfully point out that the v5.5.1 patch might have actually brought along a breaking change, depending on your definition of “breaking change” 😉

We use Mind Renovate to manage our package upgrades automatically. We also use jest-fail-on-console to help keep on top of both, what I call, our “test barf” and to help us be a bit more careful about what non-critical warnings and errors might be raised and subsequently ignored by us during development.

Anyway, when Renovate tried to upgrade to react-select-event to v5.5.1 we started getting a failing build on that branch due to a new act-style warning being thrown… you know the one:

    Warning: An update to WhateverComponentLol inside a test was not wrapped in act(...).

    When testing, code that causes React state updates should be wrapped into act(...):

    act(() => {
      /* fire events that update state */
    });
    /* assert on the output */

... snip ...

I just wanted to point this out because it was unexpected in a patch release and the removal of the act call seems like the entire reason why this patch was released in the first place.

We’re on react 17.0.2 and @testing-library/react 12.1.5 for what it’s worth which seems to meet this project’s devDependencies requirements.

[antonvialibri1]

@curtvict

I have found a workaround for now, I’m sharing it here so hopefully it helps you as well.

The following code doesn’t cause the dreaded act warning:

import selectEvent from 'react-select-event';
import { act, render, screen, waitFor } from '@testing-library/react';
// ...

// In test:
await act(async () => 
  await selectEvent.select(
    select,
    ['TagA', 'TagB', 'TagC']
  );
);
expect(screen.getByText('TagA')).toBeInTheDocument();
expect(screen.getByText('TagB')).toBeInTheDocument();
expect(screen.getByText('TagC')).toBeInTheDocument();

With this code, there’s no act warning for me.

☝️ But… The test above didn’t pass. I noticed that when you pass an array of options to selectEvent.select like I did with ['TagA', 'TagB', 'TagC'], only the last options ends up being added to the select for some reason (in my case as I’m using React 18, I suppose that it has to do with React 18’s Auto Batching, but I’m not sure as I didn’t dig deeper).

So what I did was selecting one option at a time, and ended up with this working code:

import selectEvent from 'react-select-event';
import { act, render, screen, waitFor } from '@testing-library/react';
// ...

// In test:
const select = screen.getByRole('textbox', {
  name: /Tags/i
});

// Select one option at a time, reopening the react-select's dropdown each time.
// After all, that's how our users will end up using this component...
selectEvent.openMenu(select);
await act(async () => 
  await selectEvent.select(
    select,
    'TagA'
  );
);

selectEvent.openMenu(select);
await act(async () => 
  await selectEvent.select(
    select,
    'TagB'
  );
);

selectEvent.openMenu(select);
await act(async () => 
  await selectEvent.select(
    select,
    'TagC'
  );
);

expect(screen.getByText('TagA')).toBeInTheDocument();
expect(screen.getByText('TagB')).toBeInTheDocument();
expect(screen.getByText('TagC')).toBeInTheDocument();

A bit of boilerplate, but at least it works and doesn’t give any error/warning in my case.

Hope it helps someone who’s facing a similar issue.

[antonvialibri1]

@nntdias Thanks for pointing that out, I updated the code snippets.