Tests not failing when expectations are not met

[jdmunro]

If I set up a test that should fail because the dispatched actions do not meet the expectations, the test is in-fact passing which can be quite dangerous.

This is using redux-mock-store 0.0.6 and Jest 0.8.2.

I believe the problem lies here:

} catch (e) {
  if (done) {
    done(e);
  }
  throw e;
}

I was able to cause the test to fail as expected by simply not calling done, e.g:

} catch (e) {
  if (done) {
    //done(e);
  }
  throw e;
}

I'm not 100% sure if this is an issue with this library or one with Jest, therefore I have not put together a PR yet until the matter has been discussed.

[arizzitano]

I just noticed this too. Tests pass even if I pass junk into the mockStore() init call, e.g. mockStore('asdf', done). Using redux-mock-store 0.0.6 with jasmine/karma and mocking XHRs with karma-jasmine-ajax.

[jwbennet]

I believe that this library supports Mocha instead of Jasmine and the two libraries differ on how they use the done function. With Mocha, calling the done function with an error will fail the spec, but in Jasmine there is a special done.fail function which needs to be called to fail the spec (see the docs for async support). For now I'm working around it by passing in the done function like this:

const store = mockStore({ }, expectedActions, (e) => {
      if(e instanceof Error) {
        done.fail(e);
      } else {
        done(e);
      }
    });

[jdmunro]

Thanks @jwbennet your explanation makes complete sense, I'll use your workaround. I don't know if @arnaudbenard is interested in also supporting Jasmine. I can maybe put together a PR, if not feel free to close this issue.

[arizzitano]

@jwbennet thanks for the workaround!

@jdmunro @arnaudbenard +1 for Jasmine support (or a framework-agnostic fork).

[arnaudbenard]

Is there an easy method to detect if we are using Jasmine or mocha?

If that's the case, I'm happy to support Jasmine

[jdmunro]

I had a pragmatic solution in mind:

if (done.fail) {
    done.fail(e);
} else {
    // ... current exception handling.
}

It isn't the most robust solution but it should do the trick for now. Alternatively we can just look for the presence of the jasmine variable.

[erquhart]

I think the greater issue here is how redux-mock-store bypasses my assertion library. I've put a fair amount of time into integrating redux-mock-store into my tests, and I now feel strongly that this is an anti-pattern that will probably bite a lot of folks.

A mocking lib should not handle setting expectations. It should simply provide an interface that helps devs run isolated test scenarios. A mocking lib shouldn't need to support any test framework - it's probably fair to say the issue of supporting mocha vs jasmine is an xy problem.

For now I'll be using spies when I need to mock around stores, but I do love the idea of using a lib like this - it just needs less responsibility. I guess we'll see if the guy who's actually doing something about this for the community agrees :)

At any rate, thanks for your work, mate.

[arnaudbenard]

I agree with @erquhart. The library should be framework agnostic. I have noticed that other people had problems with Jasmine and tape as well. I am not sure how to handle that yet. Do you have examples of libraries that have the same type of API?

[erquhart]

I've commented on #22.

Thanks for the workaround @jwbennet

[nikolasleblanc]

In the meantime, here's a temporary module for Jasmine (and Mocha): https://www.npmjs.com/package/redux-mock-store-jasmine

[arnaudbenard]

There's a new version out, please give it a try 👊