Future-Proof your Mutations

Shannon Archer — Tue, 08 Oct 2019 10:09:02 +0000

Recently I began expunging mutations from the Vue application I work on as the way we were using them served no purpose and simply cluttered the application with pointless boilerplate, and tests for that boilerplate.

After doing this and planning on writing an opinionated post about how mutations are pointless and hinted as obsolete by Vue's creator Evan You, I did a bit of research. I quickly discovered that they can be useful as an abstraction layer but are most likely not leveraged as such in most applications and probably shouldn't be anyway.

What are Mutations?

Mutations are designed mainly as a way of tracking atomic changes to the state for debugging. They are necessary due to language limitations in ES5. However, this is no longer an issue with the eventual adoption of ES6 Proxies by most modern browsers.

How can they be useful?

Mutations can be leveraged as a useful abstraction of your state layer. For example,

commit('startLoadingBlogs');
const blogs = await getBlogs();
commit('completeLoadingBlogs', blogs);

which can be useful for debugging as this gives a more immediate overview of what is happening in your application. You're most likely to find the following in your application though,

commit('setLoading', true);
const blogs = await getBlogs();
commit('setLoading', false);
commit('setBlogs', blogs);

which reduces this potential abstraction layer to useless boilerplate.

Mutations can also be used as a logical point to validate data before committing it to state. Preventing state corruption is very important in avoiding hard to track bugs and can easily happen when directly committing API responses or user input.

Is that valuable enough to keep writing Mutations?

I've personally never had an issue debugging changes to application state using breakpoints and following the logical flow of the application. Also, the Vue debugger is useful in inspecting the state tree with each change but a quick overview of each change hasn't been a significant factor in resolving any issues I've encountered.

Bulletproofing your application with validation is the only good reason I can find for useful mutations. However, (arguably) this should be happening before your action ever gets to your commit. That is if your API returns an unexpected response your service layer should handle that as an error instead.

With this in mind, I'll continue designing for a future without commits by removing individual modules mutations and replacing it with a generic state mutator. And save me the trouble of,

No longer needing to write benign tests that simply assert that state has been changed.
No longer needing to have both actions and commits open to understanding the data flow of my application.

Write Great Tests for Vuex

Shannon Archer — Sun, 06 Oct 2019 20:46:06 +0000

After reading this post you should go over to Manning's website, purchase and then read "Testing Vue.js Applications" by Edd Yerburgh, the author of @vue/test-utils and the testing expert on the Vue core team.

After working with Vuex for two years, I explain the two methods I've used for testing my application's store and which one I've found to be more effective in a growing enterprise application.

Test the Whole Module

Test our entire module, actions / commits / getters, together by creating an instance of our Vuex store and testing through the store's interface.

This level of testing crosses the line into integration testing (with all its positives and negatives) but since our actions, mutations and getters are so highly coupled anyway it can make sense for a few reasons.

+ We test commits and actions together. Dispatching actions and then checking that all of our external actions, service calls and state changes occur seems like a sensible and intuitive way of testing our module.

+ When refactoring we are more likely to catch bugs in the communication of actions, commits and getters.

+ By only being able to build state through our actions when testing our getters, our coverage tools will give immediate feedback when branches of code are no longer reachable in the module.

However,

- We need to create an instance of the store with all other module dependencies. This can create extra boilerplate that then needs to be maintained and updated.

- I've found that while this method works well for small apps with fairly decoupled modules, it won't scale as our application becomes more complex.

- In the hands of a poor developer, this method can quickly become a hard-to-read, unmaintainable mess.

For example,

// app.module.spec.js
import Vuex from 'vuex';
import AppModule from '~store/app.module';
import merge from 'lodash/merge';

// a factory function is a good way 
// of DRY-ing up your tests
function createStore() {
    const getPosts = jest.fn();
    return {
        store: new Vuex.Store({
            modules: {
                app: AppModule,
                blog: { // a mocked dependency
                    namespaced: true,
                    actions: {
                        getPosts,
                    },
                },
            },
        }),
        spies: {
            // use the full path to the action
            // to make it clear what module it is in
            'blog/getPosts': getPosts, 
        },
    };
}

test('refreshing app state', async () => {
    const {store, spies} = createStore();
    const refreshPromise = store.dispatch('app/refresh');

    expect(store.getters['app/isLoading']).toBeTruthy();
    expect(spies['blog/getPosts']).toHaveBeenCalled();
    await refreshPromise;
    expect(store.getters['app/isLoading']).toBeFalsy();
});

test('refreshing app state failure', async () => {
    const error = new Error();
    const {store, spies} = createStore();
    spies['blog/getPosts'].mockImplementation(() => throw error);

    const refreshPromise = store.dispatch('app/refresh');
    expect(store.getters['app/isLoading']).toBeTruthy();
    expect(spies['blog/getPosts']).toHaveBeenCalled();
    await refreshPromise;
    expect(store.getters['app/error']).toBe(error);
    expect(store.getters['app/isLoading']).toBeFalsy();
});

Test the Parts of the Module

Test our module by testing each of the parts (actions, commits, getters) that make up the module directly.

+ This is the quickest and most maintainable way of testing a module, especially when refactoring.

+ It scales with the complexity of our module as we have full control over the parameters we are feeding the unit.

+ By staying true to unit testing we get easy-to-write tests.

However,

- Because we aren't testing the integration of the parts of the module this method won't protect against that kind of bug. The main caveat of unit testing.

- A poor developer can quickly fall into the common trap of writing tests that contain far too many implementation details i.e. test('don't call getBlogs when isLoading is true').

For example,

// app.actions.spec.js
import Vuex from 'vuex';
import {refresh} from '~store/app.actions';
import merge from 'lodash/merge';

test('refreshing app state', async () => {
    const store = {
        commit: jest.fn(),
        dispatch: jest.fn(),
    };

    await refresh(store);
    expect(store.dispatch).toHaveBeenCalledWith('blog/getPosts', null, {root: true});
});

test('refreshing app state failure', async () => {
    const error = new Error();
    const store = {
        commit: jest.fn(),
        dispatch: jest.fn().mockImplementationOnce(() => throw error),
    };

    await refresh(store);
    expect(store.dispatch).toHaveBeenCalledWith('blog/getPosts', null, {root: true});
    expect(store.commit).toHaveBeenCalledWith('setError', error)
});

Final thoughts

At the end of the day, you as a developer need to look at your testing strategies and find the balance between the different kinds of tests to maximise bug reduction and the reliability of your application.

I have written tests in both of the ways mentioned above while at Zoro. For the purpose of confidently shipping bug-free changes to my applications Vuex store, testing actions, commits and getters directly provides the right balance between ease-of-writing and reliability when accompanied by a suite of e2e tests.

DEV Community: Shannon Archer

Future-Proof your Mutations

What are Mutations?

How can they be useful?

Is that valuable enough to keep writing Mutations?

Write Great Tests for Vuex

Test the Whole Module

For example,

Test the Parts of the Module

For example,

Final thoughts