Current implemention doesn't allow Jest or any other mock tool to spy on dispatch or getState about redux-thunk HOT 2 CLOSED

For what it's worth, we usually don't want to encourage mocking like this too much. It is often overused and gives very little actual confidence to test these little units instead of testing actual store interactions with all the moving parts included.

If you want to do something like this, you could create a store enhancer to enable that behavior for your code base, but I'm not too much in favor of adding more code on our side to enable a feature that we actually want to discourage.

An example enhancer could look like this:

import { configureStore } from "@reduxjs/toolkit";
import { Store, StoreEnhancer } from "redux";

const mockableEnhancer: StoreEnhancer<
  {
    mockable: Pick<Store, "dispatch" | "getState">;
  },
  {}
> = (next) => (...args): any => {
  const store = next(...args);
  const mockable = {
    dispatch: store.dispatch,
    getState: store.getState
  };
  return Object.assign({}, store, {
    mockable,
    getState() {
      return mockable.getState();
    },
    dispatch(action: any) {
      return mockable.dispatch(action);
    }
  });
};

const store = configureStore({
  reducer: () => 0,
  enhancers: (e) => e.concat(mockableEnhancer)
});

// now we mock
store.mockable.getState = () => "foo";

// and thunks access the mock
store.dispatch((dispatch, getState) => {
  console.log(getState());
});

from redux-thunk.

@phryneas I'm in agreement with you, I think the best idea would be to have a store that is not a singleton and only load the slices of it that are required in your tests.
But legacy code sometimes requires getting worst before getting better.

The test is hard, and forcing it to test in a way that people and architectures are not prepared to do could cause discourage people to test at all, or simply tag tests as impossible.

Also, I think there is a very valid scenario where you want to keep your test slim, fast and quick to write, by testing Components Integrated with the store for a happy path and a sad path, but other scenarios can just be covered with a contract test, which this PR helps to achieve.
Also, scenarios where you create a common (internal) component library where part of the API is that your components dispatch actions to be handled in consumers' apps. In the current status will force you to write TestDoubles when a simple could solve the issue.
I think limiting the kind of tests that you prefer to discourage can prevent other kinds of architectures that you are not thinking about right now, which are totally valid and could benefit from this change, and also transition states in big and legacy projects.

The enhancer you propose will require adding a Test code to production code, as the store is exactly the same as it is for production, and adding this enhancer only on test via an env prop could be even worst than my proposed solution.

In my opinion, it's always better to allow to test in any way possible, than force people to test in your opinionated way (which I agree with). Encourage them to test better but never force nor limit.

I think in the industry we suffer too much elitism as regard testing and how is supposed to be tested, or TDD is king and we are creating a toxic environment for those that are outside of the "good practices" (personally follow TDD, and Kent Beck's ideas)

Just as a last argument, if I mock store.getState or store.dispatch, I expect to be mocked I don't expect to be cached by a library.

I truly hope you change your mind about this. I know it can be annoying to accept a PR like this from your point of view, but because there are bad cases to use, are also valid and helpful ones.

Cheers!

from redux-thunk.