Tests

Les parties principales que l'on veut couvrir par des tests unitaires avec Vuex sont les mutations et les actions.

Tester les mutations

Les mutations sont très simples à tester, puisque ce sont de simples fonctions qui se basent uniquement sur leurs arguments. Une astuce est que si vous utilisez les modules ES2015 et mettez vos mutations dans votre fichier store.js, en plus de l'export par défaut, vous pouvez également exporter vos mutations avec un export nommé :

const state = { ... }

// exporter `mutations` en tant qu'export nommé
export const mutations = { ... }

export default new Vuex.Store({
  state,
  mutations
})

Exemple de test de mutation utilisant Mocha + Chai (vous pouvez utiliser n'importe quel framework/bibliothèque d'assertion selon vos préférences) :

// mutations.js
export const mutations = {
  increment: state => state.count++
}

// mutations.spec.js
import { expect } from 'chai'
import { mutations } from './store'

// assignement de `mutations` par déstructuration
const { increment } = mutations

describe('mutations', () => {
  it('INCREMENT', () => {
    // état simulé
    const state = { count: 0 }
    // appliquer la mutation
    increment(state)
    // tester le résultat
    expect(state.count).to.equal(1)
  })
})

Tester les actions

Les actions sont un peu plus compliquées car elles peuvent faire appel à des APIs externes. Lorsque l'on teste des actions, on a souvent besoin de faire plusieurs niveaux de simulation. Par exemple, on peut abstraire l'appel API dans un service et simuler ce service dans nos tests. Afin de simuler facilement les dépendances, on peut utiliser webpack et inject-loader pour regrouper nos fichiers de test.

Exemple de test d'une action asynchrone :

// actions.js
import shop from '../api/shop'

export const getAllProducts = ({ commit }) => {
  commit('REQUEST_PRODUCTS')
  shop.getProducts(products => {
    commit('RECEIVE_PRODUCTS', products)
  })
}

// actions.spec.js

// utilisation de la syntaxe `require` pour les loaders.
// avec inject-loader, cela retourne un module de fabrique
// cela nous permet d'injecter les dépendances simulées.
import { expect } from 'chai'
const actionsInjector = require('inject-loader!./actions')

// créer un module avec nos simulations
const actions = actionsInjector({
  '../api/shop': {
    getProducts (cb) {
      setTimeout(() => {
        cb([ /* réponse simulée */ ])
      }, 100)
    }
  }
})

// fonction utilitaire pour tester des actions avec les mutations attendues
const testAction = (action, args, state, expectedMutations, done) => {
  let count = 0

  // acter une simulation
  const commit = (type, payload) => {
    const mutation = expectedMutations[count]

    try {
      expect(mutation.type).to.equal(type)
      expect(payload).to.deep.equal(mutation.payload)
    } catch (error) {
      done(error)
    }

    count++
    if (count >= expectedMutations.length) {
      done()
    }
  }

  // appeler l'action avec le store simulé et les arguments
  action({ commit, state }, ...args)

  // vérifier qu'aucune mutation n'ait été propagée
  if (expectedMutations.length === 0) {
    expect(count).to.equal(0)
    done()
  }
}

describe('actions', () => {
  it('getAllProducts', done => {
    testAction(actions.getAllProducts, [], {}, [
      { type: 'REQUEST_PRODUCTS' },
      { type: 'RECEIVE_PRODUCTS', payload: { /* mocked response */ } }
    ], done)
  })
})

Si vous avez des espions disponibles dans votre environnement de test (par exemple via Sinon.JS), vous pouvez les utiliser à la place de la fonction utilitaire testAction :

describe('actions', () => {
  it('getAllProducts', () => {
    const commit = sinon.spy()
    const state = {}
     actions.getAllProducts({ commit, state })
     expect(commit.args).to.deep.equal([
      ['REQUEST_PRODUCTS'],
      ['RECEIVE_PRODUCTS', { /* réponse de la mockup */ }]
    ])
  })
})

Tester les accesseurs

Si vos accesseurs font des calculs compliqués, il peut être judicieux de les tester. Les accesseurs sont également très simples à tester, pour les mêmes raisons que les mutations.

Exemple de test d'un accesseur :

// getters.js
export const getters = {
  filteredProducts (state, { filterCategory }) {
    return state.products.filter(product => {
      return product.category === filterCategory
    })
  }
}

// getters.spec.js
import { expect } from 'chai'
import { getters } from './getters'

describe('getters', () => {
  it('filteredProducts', () => {
    // état simulé
    const state = {
      products: [
        { id: 1, title: 'Apple', category: 'fruit' },
        { id: 2, title: 'Orange', category: 'fruit' },
        { id: 3, title: 'Carrot', category: 'vegetable' }
      ]
    }
    // accesseur simulé
    const filterCategory = 'fruit'

    // obtenir le résultat depuis l'accesseur
    const result = getters.filteredProducts(state, { filterCategory })

    // tester le résultat
    expect(result).to.deep.equal([
      { id: 1, title: 'Apple', category: 'fruit' },
      { id: 2, title: 'Orange', category: 'fruit' }
    ])
  })
})

Lancer les tests

Si vos mutations et actions sont écrites comme il se doit, les tests ne devraient pas avoir de dépendance directe sur les APIs navigateur après une simulation préalable. Cela signifie que vous pouvez simplement regrouper les tests avec webpack et les lancer directement dans Node.js. De façon alternative, vous pouvez utiliser mocha-loader ou Karma + karma-webpack afin d'effectuer les tests dans des vrais navigateurs.

Lancer dans Node.js

Créez la configuration webpack suivante (ainsi que le fichier .babelrc qui correspond) :

// webpack.config.js
module.exports = {
  entry: './test.js',
  output: {
    path: __dirname,
    filename: 'test-bundle.js'
  },
  module: {
    loaders: [
      {
        test: /\.js$/,
        loader: 'babel-loader',
        exclude: /node_modules/
      }
    ]
  }
}

Puis :

webpack
mocha test-bundle.js

Lancer dans un navigateur

Installez mocha-loader.
Changez l'option entry de la configuration webpack ci-dessus pour 'mocha-loader!babel-loader!./test.js'.
Démarrez webpack-dev-server en utilisant la configuration.
Rendez-vous avec votre navigateur sur localhost:8080/webpack-dev-server/test-bundle.

Lancer dans un navigateur avec Karma + karma-webpack

Consultez la procédure sur la documentation vue-loader.

# Tests

# Tester les mutations

# Tester les actions

# Tester les accesseurs

# Lancer les tests

# Lancer dans Node.js

# Lancer dans un navigateur

# Lancer dans un navigateur avec Karma + karma-webpack