Vue TDD - Vuex 편

Table of Content

• Introduction
• Testing state
• Testing getters
• Testing mutations
• Testing actions
• Conclusion
• Reference

📌00. Introduction

이번편에서는 vuex를 테스팅하는 방법에 대해 공유하고자 합니다. 해당 코드는 vue-test-practice에서 확인할 수 있습니다.🎉

해당 편에서는 기본적으로 Component편의 counter를 구현하는 예제에서 api mock을 실제로 실현 해보기 위해 json placeholder에 todos를 불러오는 예제도 같이 진행하려고 합니다.

📌 01. Testing State

state는 보통 getDefaultState 같은 함수형으로 선언을 해주는것이 좋습니다. 그이유는 testing을 할때 좀더 편하게 state의 값을 초기화 시켜줄 수 있기 때문입니다.

// Store.spec.js
import counterStore, { getDefaultState } from '@/store/modules/counter'; // 스토어를 불러옵니다.
const { state, getters, mutations, actions } = counterStore; // 디스럭터링을 사용

// state는 항상 초기 값은 getDefaultState의 리턴 값이어야 합니다.
describe('State test', () => {
  it('state should be equal getDeFaultState()', () => {
    expect(state).toEqual(getDefaultState());
  });
});

// counter.js

export const getDefaultState = () => ({
  count: 0,
  items: [],
});

export default { namespaced: true, state: getDefaultState(), getters, mutations, actions };

📌 02. Testing getters

getters에는 카운트가 0이냐 아니냐는 함수를 선언해보겠습니다.

// Store.spec.js
describe('Getters test', () => {
  describe('isCountZero test', () => {
    it('count 0 should be true', () => {
      const state = { count: 0 };
      // count의 값이 0이기 때문에 true이어야 합니다.
      expect(isCountZero(state)).toBeTruthy();
    });
    it('count 1 should be false', () => {
      const state = { count: 1 };
      // count 값이 0이 아니기 때문에 false이어야 합니다.
      expect(isCountZero(state)).toBeFalsy();
    });
  });
});

// counter.js
const getters = {
  isCountZero: state => state.count === 0,
};

📌 03. Testing mutations

다음과 같은 두가지 mutations를 선언해보겠습니다.

• INCREMENT: count의 값을 1증가 시킴
• DECREMENT: count의 값을 1감소 시킴

// Store.spec.js

const { INCREMENT, DECREMENT } = mutations;
describe('Mutation test', () => {
  let state;
  // 매 테스트 직후 state값을 초기화 시켜줌
  beforeEach(() => {
    state = getDefaultState();
  });
  describe('Increment test', () => {
    it('Increment state by 1', () => {
      INCREMENT(state);
      // 한번 INCREMENT를 해주었으니 state.count의 값은 1이 나와야합니다.
      expect(state.count).toBe(1);
    });
  });

  describe('Decrement test', () => {
    it('Decrement state by 1', () => {
      DECREMENT(state);
      // 한번 DECREMENT를 해주었으니 state.count의 값은 -1이 나와야합니다.
      expect(state.count).toBe(-1);
    });
  });
});

// counter.js
const mutations = {
  [INCREMENT](state) {
    state.count += 1;
  },

  [DECREMENT](state) {
    state.count -= 1;
  },
};

📌 04. Testing actions

일반적으로 actions에는 보통 api같은 비동기 작업이 들어갑니다. 따라서 json placehoder에서 todos를 불러오는 작업을 해보겠습니다.

먼저 todos를 불러오는 api call은 이렇게 짤수 있습니다.

import * as axios from 'axios';

export const fetchData = () => {
  return axios.get('https://jsonplaceholder.typicode.com/posts/1'); // 1개의 포스트만 불러오는 api
};

하지만 실제 테스트는 해당 api의 값을 그대로 받는 것이 아닌 mock을 해줘야 합니다.

// Store.spec.js
import { fetchData } from '@/api/todo-service';
import { mockItems } from '../__mock__/item-mock';

// 해당 서비스를 jest mock 해줍니다.
jest.mock('@/api/todo-service');


describe('Async actions test', () => {
  describe('Fetch items test', () => {
    it('get items from mock', async () => {
      // 이부분에서 내려올 값을 지정을 해줍니다.
      fetchData.mockResolvedValue(mockItems);
      // mockItem은 이렇게 생겼습니다.

      // export const mockItems = {
      //  data: [1, 2, 3],
      // };

      // sinon.spy()와 사용법이 같습니다.
      // commit이 어떻게 호출이 되었는지 jest에서 감시해줍니다.
      const commit = jest.fn();
      await FETCH_ITEMS({ commit });
      expect(commit).toHaveBeenCalledWith('SET_ITEMS', mockItems.data);
    });
  });
});

// Store.spec.js

const actions = {
  async [FETCH_ITEMS]({ commit }) {
    const response = await fetchData();
    commit(SET_ITEMS, response.data);
  },
};

🤔번외 라이브러리 mock하기

대표적으로 쓰이는 nanoid를 mock해보겠습니다.

import nanoid from 'nanoid';

/**
 * mocking nanoid
 */
jest.mock('nanoid');
let value;
// String으로 1부터 증가된것을 리턴합니다.
nanoid.mockImplementation(() => {
  return String((value += 1));
});
// 테스트가 끝난후 0으로 초기화를 해줍니다.
beforeEach(() => {
  value = 0;
});
// 테스트가 모두 끝난후에 다른 테스트에 영향을 미칠수 있으므로 nanoid를 되돌려 놓습니다.
afterAll(() => {
  nanoid.mockRestore();
});

📌 05. Conclusion

테스트 코드를 짠다는것을 살펴보았습니다. 테스트코드를 짠다는것은 각각의 코드를 짜는 것의 시간이 더 들어가는 것이 사실입니다. 하지만 정확한 코드들로 하나하나 쌓아간다면 전반적인 시간을 훨씬 더 단축시킬 수 있습니다. 간혹 mutations와 같은 간단한 것들은 왜 test code를 짜는지 모르겠다는 사람들이 있습니다. 이는 두가지 관점에서 좀더 살펴봐야할 필요가 있습니다.

첫 번째 관점은 test code를 작성하는 것은 문서의 역할을 하기 때문입니다. mutations에 정확하게 어떠한 값들이 들어가는지 어떤 타입들이 들어가는지 정확하게 알아야 할 필요성이 있을 때가 있습니다. 하지만 실제로 돌려서 확인하기에는 단계가 복잡한 경우도 있고 한눈에 보기가 어려워 집니다.

두 번째 관점은 test code가 사소한 버그를 잡아주기 때문입니다. 간혹 저는 이런 실수를 하곤 합니다. state에 tset라고 선언이렇게 설정을 하고
mutations에는 또 정확하게 state.test = 1; 이렇게 해놓는 경우가 있습니다. 이런 경우 버그를 잡는데 시간이 정말 많이 소요가 됩니다. 이런 자잘한 버그들을 잡아주기 때문에 testcode를 씁니다.

하지만 모든 코드들을 100% tdd로 가는것은 부적합합니다. 그리고 100% test code를 신뢰하는것 또한 위험하다고 생각합니다.(test case의 부재 혹은 test case가 잘못되었을 가능성도 있기 때문에) 하지만 마치 mutations type을 상수화를 해놓는 것처럼 자잘한 버그부터 치명적인 버그는 꽤많이 잡아줄 수 있다고 생각합니다. 따라서 필요에 따라 tdd를 쓰는 것을 권장합니다. 또한 test의 종류는 여러가지 입니다. unit test로만 모든 test를 커버하려고 하지 마세용... 😅

이번 포스팅 까지는 vue의 logic적인 것을 살펴 보았다면 다음 포스팅에서는 vue의 view적인 것을 테스트 하는 방법에 대해 알아보겠습니다.(Story Book)

📌 Reference

• Vuex 공식 문서
• Vue test utils