Question about appropriate testing strategy for dispatch returns

[kwhitaker]

This is probably my limited understanding of async JS unit testing coming through, but I have a question about the appropriate strategy for testing actions dispatched by redux-thunk.

I have an action to log users out of a system:

export function logout() {
  return dispatch => {
    return request.del(`/session/logout`)
      .then(() => {
        setUserCookie({});
        dispatch(receiveUser({}));
      }, (error) => {
        dispatch(receiveUserError(error.message));
      });
  };
}

I'm using Jasmine as my testing framework, but I'm less interested in framework specifics as I am about testing the various parts of this function.

I can easily assert that logout() returns a function, but should I then execute that function and test it as well, and so on down the chain? If this isn't the right place for this, I'll drop it on Stack or somewhere where it belongs :)

Thanks so much

[gaearon]

What specifically do you want to test in it? Control flow? Would you mock network request or let them happen?

[kwhitaker]

The network request would get mocked. And I suppose I'm looking to test control flow; when the action is called, does it a: return the expected function and b: does that function do what is expected of it.

I'm wondering now if that's an acceptable test or not; it seems like it could be brittle.

[kwhitaker]

I ended up (crudely) coming up with the following solution: https://gist.github.com/kwhitaker/f0d8624af9061f3bd8a9

The setTimeout calls are ugly, but they work.

[gaearon]

You don't need setTimeout, use store.subscribe().
reduxjs/redux#546 (comment)

[salmanm]

@kwhitaker How did you mock network requests in this case? Did you dispatch an action yourself, simulating async action dispatch which has the response object?

[kwhitaker]

@salmanm I used Jasmine AJAX to handle that:

    let request = jasmine.Ajax.requests.mostRecent();
    expect(request.url).toBe(`${BSPACE_URL}/connectors/builds`);
    request.respondWith({
      status: 200,
      contentType: 'application/json',
      responseText: JSON.stringify(testBuilds)
    });

[just-boris]

I am testing my react-component and check that it calls dispatch in an appropriate place.

To check that my action creator returned the proper function, I use named function and check its name:

//action creator
export function fetchData(query) {
    return function fetchDataAction(dispatch) {/*some loading logic here*/}
}

//dispatch
onLoadClick() {
  this.props.dispatch(fetchData(this.props.query));
}

//test
const dispatch = jasmine.createSpy();
const component = renderIntoDocument(<Component dispatch={dispatch} />);
Simulate.click(findRenderedDOMComponentWithClass(component, 'load-button'));
expect(dispatch).toHaveBeenCalledWith(jasmine.objectContaining({name: 'fetchDataAction'}))

function.name is used here as a kind of type property for plain action objects. Am I doing this right? Can this be considered as a common practice?

[salmanm]

@just-boris
Ideally, I would test some changes in the state or spy some underlying library to check if the call has been made using the correct query parameter.

For example, I had one lib containing all util functions which take care of ajax calls, I imported that and stubbed callAPI function.

Testing against function name doesn't look very useful. Because the test would pass as long as the function name is same even if the the function behaviour has changed, which should ideally fail the test.

[just-boris]

@salmanm
I want to keep my test on components clear from side-effects. Of course, I have tests with store and action create logic, but they are separated from tests with React components.

I did it because it is easier to test isolated store and its action handling logic, including ajax calls.

My point was in that it is nice to have mocked dispatch for React-components and just check that a component calls dispatches in the proper order.

UPD: there is an example of my tests:

• test on store
• test on React component