How to update the store for the mock store? about redux-mock-store HOT 16 CLOSED

here's my case for a semi integration, by which I mean action fires hits reducer updates store.
If i unit test each of the individuals then I know they are all sound which is great. But really they are just as sound as the input I SAY it should get and the result I SAY it should produce.
If I test my action and I say it should have a payload of an object and I test it and it does then great!
If I test my reducer and say the action should provide an array and update state and it does then great!
but in reality that isn't going to work. I have a test that tests the full circuit then I know my action matches what my reducer expects and my reducer processes the payload that the action provides.
Further, my particular case is that I would like to do more of an integration test so that my action actually goes to the api and thus must have the proper values, and what the api returns his the reducer and the reducer is handling what actually comes back.
Just my two cents.
thanks.

from redux-mock-store.

I had the same issue. I created a pull request with the changes to allow to update the sate of the redux store. This will allow to see the changes on the component state.

With my changes you have to replace the reducer in the mock store with your reducer to be able to update the state when a dispatch happen. Here's an example of how to use the mock store.

const store = configureMockStore()({
  players: {
      'audio-player-1': { paused: false }
  }
});
store.replaceReducer(reducer);
wrapper.simulate('click');
expect(dispatchSpy).toHaveBeenCalledWith(play(id));

#86

from redux-mock-store.

I just think it is important to simulate the user behaviour and test the end to end result of some user interaction. I had the same need as @MartinDawson so I just thought it would be nice to have that but if the library was only designed to test actions, it's ok.

One example of a test I would like to update the redux store is the follow:
My view starts with an empty store and no data in the screen so I'm expecting that the view will trigger an action to request data and after a few seconds the view will have the data that my fake API returned. But yes I can test the view, the reducer and the action individually I'm just used to make also an end to end test.

from redux-mock-store.

@catarinasoliveira this is actually not a use case for mockStore.
MockStore is good for unitTesting because it is simple.
In end-to-end tests would be easier to use the real redux with real reducers.

Then you will be able to test your connected component and mock api responses.

But still much easier to test separately each part (component, reducers, action creators).

from redux-mock-store.

Here's my use case. I have a component, which triggers some actions on mount (fetching data). So the only way I can unit test that it renders correct stuff is that I mount the component with the mock store and right after I have to update the state in the store so my component can react through mapped props.
I know that using componentWillReceiveProps is deprecated, but now I cannot see how can I test it as now I cannot send new props through mapStateToProps

from redux-mock-store.

So based on your example from stackoverflow, instead of doing:

it('onClick toggles play if paused', () => {
  store.dispatch(updateOption('paused', true, id));
  wrapper.simulate('click');
  expect(dispatchSpy).toHaveBeenCalledWith(play(id));
});

You would do:

it('onClick toggles play if paused', () => {
  const store = configureMockStore()({
    players: {
      'audio-player-1': { paused: true }
    }
  });
  wrapper.simulate('click');
  expect(dispatchSpy).toHaveBeenCalledWith(play(id));
});

from redux-mock-store.

@catarinasoliveira This adds unneeded complexity to the store. The idea of current implementation is that you can recreate store for each new action which you test.

from redux-mock-store.

@dmitry-zaets, @arnaudbenard

Thanks for replying.
My main problem was that the store wasn't updating dynamically when I used enzymes setContext to try and update the store (it still had the old values).

Instead of using setContext to a new store, I now overwrite the mock store on each of my tests.

Do you know why wrapper.setContext({ context: newStore}); doesn't work though?

Here's new code, is this okay?

describe('Play Container', () => {
  const id = 'audio-player-1';

  let wrapper;
  let store;

  const renderWrapper = (state) => {
    store = mockStore(state);
    expect.spyOn(store, 'dispatch');
    wrapper = shallow(
      <PlayContainer />
      { context: { id } },
    ).shallow({ context: { store } });
  };

  beforeEach(() => {
    renderWrapper({ paused: false });
  });

  it('onClick toggles play if paused', () => {
    renderWrapper({ paused: true });
    wrapper.simulate('click');
    expect(store.dispatch).toHaveBeenCalledWith(play(id));
  });
  it('onClick toggles pause if playing', () => {
    wrapper.simulate('click');
    expect(store.dispatch).toHaveBeenCalledWith(pause(id));
  });
});

This works well but it's more complex than simply setting wrapper.setContext() in each test which would be ideal.

from redux-mock-store.

There is no way to update mocked store state because usually it is not needed. You can just create a new instance of mockStore if you need to change the state.

from redux-mock-store.

@dmitry-zaets That doesn't work. It doesn't update the components state. stateProps.paused is still false within onClick.

from redux-mock-store.

@MartinDawson why it doesn't update it? Have you debugged the problem?
Would be nice if you will be able to share some code.

from redux-mock-store.

@catarinasoliveira I agree with @dmitry-zaets. The goal of the library is to unit test the action and check which messages it will dispatch. The reducers should be tested separately. Thank you for the feedback 👍

from redux-mock-store.

Thanks @dmitry-zaets and @arnaudbenard for the explanation. I'll use a real redux store instead.

from redux-mock-store.

I would leave the discussion open, just in case if the new use-cases will appear.

from redux-mock-store.

@catarinasoliveira thank for the effort and feedback! We would like to know the result of your tryouts! If you will end up having troubles - let us know.

from redux-mock-store.

What I was doing was more end-to-end testing like @dmitry-zaets said. I think the whole point of unit-testing should be simple and test one part at a time.

This also got complicated quickly.

What I have done now is use babel-plugin-rewire to export the mapStateToProps and container components just for my tests and now I can test them individually which is a lot simpler than trying to use mock-store to do this.

from redux-mock-store.