Testing selectors that are dependent on RTK Query in isolation

[marcoturi]

I would like to test a selector that is dependent on RTK query and I would like to get a mocked state without having to know the implementation details on how RTK Query design its state:

expect(UserSelectors.getUserFullName({
      api: {
        queries: {
          'getUser(undefined)': {
            data: {
              id: '1',
              name: 'John',
              surname: 'Doe',
            },
          },
        }
      }
    })).toEqual(
      'John Doe',
    );

Instead I would like to achieve the same result in a way similar to this:

  it('Should return full name', () => {
    const expectedState = getMockedState({
      functionName: 'getUser',
      data: {
        id: '1',
        name: 'John',
        surname: 'Doe',
      },
    });
    expect(UserSelectors.getUserFullName(expectedState)).toEqual('John Doe');
  });

function getMockedState({
  functionName,
  parameters,
  data,
}: {
  functionName: string;
  parameters?: any;
  data?: any;
}) {
  const state: any = {};
  if(data) {
    state.data = data;
  }
  return {
    api: {
      queries: {
        [`${functionName}(${
          parameters ? JSON.stringify(parameters) : 'undefined'
        })`]: state,
      },
    },
  } as any;
}

I expect this to be a common scenario in modern redux testing and was wandering if there is no already built-in solution for this situation.

[EskiMojo14]

generally instead of mocking state, we recommend setting up a real store and instead using something like Mock Service Worker to intercept the (real) network requests. That way, you don't have to worry about how the reducers manage state.

[EskiMojo14]

the point of RTKQ is that the state is an implementation detail. we could change the shape of RTKQ's slice state and your code shouldn't have to care about it, so long as the thunks and selectors (and hooks) we provide work the same way.

I'd argue that mocking state is actually less maintainable than using real reducers which already know what the state they're going to handle will be, since if those reducers change your mocks also need changing.

[marcoturi]

@phryneas yeah that's what I did in the example above. Problem was that "valid mocked state" was dependent on how redux state shape is made, thus making the tests fragile. But I got it, redux toolkit supports an "integration tests approach" to overcome this situation.

the point of RTKQ is that the state is an implementation detail. we could change the shape of RTKQ's slice state and your code shouldn't have to care about it, so long as the thunks and selectors (and hooks) we provide work the same way.

I couldn't agree more on this!

I'd argue that mocking state is actually less maintainable than using real reducers which already know what the state they're going to handle will be, since if those reducers change your mocks also need changing.

Unit and integration tests have different goals and in my opinion they both are useful.

[phryneas]

Unit and integration tests have different goals and in my opinion they both are useful.

Absolutely, but once you start integrating with a third party library, you enter integration test behaviour either way - no matter what you do, you have a significant amount of "black box" in there, so in that moment it is an integration test.

[EskiMojo14]

Just a follow up on this - I've realised that you should be able to use upsertQueryData instead of using MSW, if you really wanted to:

const store = makeStore();

const newData = {
  id: "1",
  name: "John",
  surname: "Doe",
};

await store.dispatch(api.util.upsertQueryData("getUser", undefined, newData));

expect(selectUserFullName(store.getState())).toEqual("John Doe");

This of course still needs a real store, so it may not be "unit test"-y enough for you, but it means you can treat the state shape as an implementation detail.

[marcoturi]

I have implemented your suggestion @EskiMojo14 marcoturi/react-redux-boilerplate@f4a91dc thank you! This way is much much cleaner.