1

I have a <Review /> page that I want to run tests against to check if certain functionality is enabled / disabled based on the existing state in Redux.

I feel that whilst the current solution I have works, it looks messy in tests & I want to get a wider opinion on the test structure.

This is a basic test example:

it('shows `agree` button if the user has `role` of customer', async () => {
  const state = {
    user: {
      user: {
        _id: 't3stID',
        workspaces: [
          {
            preferred: true,
            member: {
              roles: ['customer'],
            },
          },
        ],
      },
    },
  };

  // Render with redux is a custom helper method that renders the component under test wrapped in `<Provider>` and the `state` passed in the args.

  const { findByRole } = renderWithRedux<DeepPartial<RootState>>(<Review />, {
    reducer, //imported
    state, // defined above
  });

  expect(await findByRole('button', { name: 'Agree' })).toBeInTheDocument();
});

Questions:

  1. Is creating the bare minimum state necessary for that test and then injecting it using the render method the correct way to do this?

  2. I have thought about creating a factory class that generates this state object using constructor values / methods to set values. Would this be a way of reducing the amount of "boilerplate" objects?

  3. What are your thoughts on creating repetitive objects like this that usually only need one property change in the state? I have thought about rendering the component in a beforeEach() but can't get my head around changing the state before each test.

Jamie
  • 3,105
  • 1
  • 25
  • 35
  • 1. & 2. Both of these seem sensible things to do. 3. I would move the state and render to a function with the variable parts as input, then call it on each test (without using `beforeEach`). – juliomalves Mar 20 '21 at 15:51

0 Answers0