Assert a Vuex Action Calls a Mutation

[GazEdge]

In some of the vuex module unit tests, when an action is tested, an assertion is run on store.state

Would it be better to assert that the action calls the correct mutator? Otherwise the action unit tests are testing too much (they are also testing that the mutations behave correctly).

Additionally, i ran into an issue where someone had modified the state directly in an action. I thought vue warned against this, but turns out the warning doesnt appear during unit tests. Testing that an action calls a mutation would mitigate against accidentally modifying the state directly in the action.

[marceloavf]

How did you get it done @GazEdge ? I'm trying to test if an action calls a mutation but no success at all.

I was able to make it work like this, but doesn't know if it is correct

it('actions.resetSelected do not commit when no component selected', () => {
      const commit = jest.fn()
      notificationCreatorModule.actions.resetSelected({
        commit,
        state: { selected: { id: null } },
      })
      expect(commit).not.toHaveBeenCalled()
    })

[chrisvfritz]

Would it be better to assert that the action calls the correct mutator?

That's a good idea. I'll update the tests shortly.

i ran into an issue where someone had modified the state directly in an action. I thought vue warned against this, but turns out the warning doesnt appear during unit tests.

In some projects, I've implemented something like this in the Jest setup file for console.error (and sometimes console.warn), but I have mixed feelings on whether it's a good idea here. I've been on some projects where a 3rd-party library emits a lot of warnings/errors even when nothing's wrong. Maybe I'll emit an error, but with instructions on how to selectively whitelist some errors/warnings as OK so that people don't get stuck.

[chrisvfritz]

I just updated Jest to fail on state mutations outside of mutations - and also any other time console.error or console.warn is called. However, I decided not to assert that the correct mutator is called, for a few reasons:

• Mocking mutations and checking for calls adds complexity to the tests for relatively little benefit and mutations may be called multiple times before settling on a final value, making tests brittle from asserting what's arguably an internal implementation detail of the action.
• In practice, updating a mutation often means also updating the actions that call that mutation, so there's some inherent coupling.
• When mutations are extremely simple (which is most of the time), they arguably don't merit their own tests, but leaving mutations unmocked and just checking for the correct state allows us to still provide coverage for them.
• In the next major version of Vuex, mutations will become an internal implementation detail, allowing actions to change state directly while still getting great logs in the devtools. That means in the future, we'll have to write tests like this anyway. Doing it now means migrating tests will be much simpler when upgrading Vuex.