시작하며

회사에서 자동화 배포 코드까지 작성하면서, 어떤 것을 더 해볼까...하며 고민하던 와중에, 테스트 코드도 도입하면 어떨까 생각했어요.

아무래도 눈에는 보이지 않더라도, 차후 반응형으로 마이그레이션 할 때 안정성을 높이기 위해 필요하다고 생각했기 때문이죠.

다만... 과연 프로젝트를 이어갈 수 있을까... (이어갔으면 좋겠네요 🥲)

각설하고, 결국 제 성장은 제가 책임져야 하니, 테스트 코드를 시작하기로 했답니다.

본론

저는 보통 vue-cli로 간단하게 세팅하는 편이에요.
물론 customization하는 것도 좋지만, 아직 현재 레벨에서의 어정쩡한 최적화보다는, 직접 지원해주는 프레임워크의 힘을 믿는 게 좋다는 판단에서입니다!

(실제로 vue에서 직접 webpack이나 vite로 커스터마이징하여 만드는 프로젝트를 보지 못한 것도 한 몫 했구요.)

이런 걸 보면, vue라는 프레임워크가 너무나 큰 CRA로 인해 직접 설정하는 react와 대비하여 좋을 때도 있는 거 같아요.

여튼, 일단 만들어줍시다!

현재 환경:
yarn v1.22.19
node v16.15.0

전역으로 vue-cli 설치

먼저 간단히 cli로 vue 프로젝트를 설치하기 위해 패키지를 설치합니다.

yarn global add vue-cli

이후 경로를 기반으로 터미널에 vue를 생성하기 위한 명령어를 작성합니다.

vue create [[경로]] (경로에 .을 쓰면 현재 위치에서 생성 됩니다.)

그렇다면 다음과 같이 터미널에 내용이 나옵니다.
저의 경우에는 현재 위치에서 생성할 것이므로 Y를 입력해줬어요.

그렇다면 이제 다음과 같이 나오는데요.
보통 위의 두 개에서 고르는 편인데, 저는 항상 맨 아래 것에서 고릅니다.
직접 하나하나 고를 수 있기 때문에, 더욱 편리하게 디테일한 설정이 가능해요!

그렇다면 다음과 같은 내용이 나오는데요.
각자 원하는 것을 골라봅시다!

여기서 우리는 jest를 위한 것이니, unit-test는 필수!

이후에는 Vue 버전을 고르라고 하는데요.
솔직히 이건 3를 권장하고는 싶긴 한데... 2를 선호하는 분들도 가끔 계시더라구요.
(아무래도 간혹가다 어떤 라이브러리는 아직 vue 2에서만 지원 가능하기 때문입니다)
따라서 각자 프로젝트의 라이브러리 의존성을 고려하면서 선택하기를 바랍니다 🙏🏻

하지만 제 글은 별 라이브러리 사용은 없어서 Vue 3를 기반으로 할 거구요, compositionAPI를 사용할 거기 때문에 vue 3을 체크합니다.

그 다음은 클래스 컴포넌트 사용할 거냐는 건데, 저는 클래스 컴포넌트는 써봤는데 제 취향이 아닌... 쿨럭...

그 다음은 좀 생소할 수 있어요.
쉽게 말하자면 타입스크립트와 바벨과의 호환성을 높이기 위한 세팅을 해줄 거냐는 겁니다.
해당 글을 보면 좀 더 이해하기 쉬울 거 같아요!

vue-router의 기본은 원래 hash mode라고 하는데요.
간혹 History mode를 쓰지 않는 분도 있으실 수도 있는데, 만약 그렇다면 N을 해주세요.
하지만 저는 History mode의 노예라 Y를 해주었습니다 :)

저는 sass 씁니다!

그리고 선호하는 린터 & 포맷터 써주면 되는데요.
저는 맨날 예전부터 airbnb로 작업해서 그런지... 딱히 너무 어렵다 싶지도 않고 편해서 airbnb rule로 보통 작업하는 편입니다 :)

그리고 이걸 설정해주면, lint-staged라는 것이 설치 돼요.
이는 pre-commit할 때 린트 검사를 수행해주고, 이후 커밋할 시점에는 깔끔하게 고쳐진 코드로 반영이 되도록 해준답니다 :) 매우 편하죠?
추후 보통 husky랑 연동해서 client hook CI로 해주기도 하더라구요!

자, 이제 대망의 테스트 코드 러너 선택이 있겠는데요.
아무래도 저는 jest를 선택했어요. 이유는 다음과 같습니다.

• 충분한 커뮤니티: 현재 테스트 코드 툴 중 가장 활발한 프레임워크입니다.
  22.07.02 Github 기준
  • mocha: 21.5k star
  • jest: 39.5k star
• 다른 부가 세팅 필요 X: 이게 좀 더 컸는데요. 아무래도 mocha 자체는 테스트 코드 러너에 가깝기 때문에 chai과 같은 test matcher나, test mock을 위한 패키지 등을 추가로 설치해야 합니다.
  다만 jest는 원래 '한 번에 쉽게 쉽게 하자~'는 철학에서 나온 페이스북이 지원하는 툴이니, 더욱 쉽게 사용할 수 있어요! (괜히 농담이라는 익살스러운 이름과, delightful이라는 슬로건이 나온 게 아니겠죠?)

다만 이런 분들은 jest를 사용하는 것을 한 번 더 생각해보시길 바랄게요!

• 나는 시간이 빨라야 하는데...?
  jest는 상대적으로 느린 편입니다. 왜냐하면 한 번 한 번의 환경을 계속해서 메인 함수를 호출하게 되는데요. 이때, 전체 프로젝트를 계속해서 독립적으로 구성하게 되는 내부 로직 때문입니다. (이 글을 참조했어요!)
  따라서 시간 때문에 jest를 포기하는 분들도 많이 있으시더라구요. 역시 결국 취향이나 비즈니스에서의 중요도에 따른 차이이니, 개발자끼리 존중해주도록 합시다 🖐🏻
  만약 그래도 시간을 단축시키고 싶다면 해당 StackOverflow 글을 참조해주시면 좋을 거 같아요!

마지막으로 이제 코드를 어떻게 작성시키는 것을 선호하는 것인가!인데요.
저는 각 설정들은 따로 분리를 해주어 응집도를 높이는 방식을 선호하는 편입니다. 따라서 위를 선택해줬어요.
만약 아래를 선택한다면, package.json에서 모든 코드들이 작성되는 로직입니다!

마지막으로 이후 프로젝트에서 항상 같은 preset으로 구성할 건지 묻는데요. 언제 바뀔지 모르니 N을 써주었습니다.

내부 코드 뜯어보기 🔍

이제 기본 CLI로 작성했다면, 내부 로직을 살펴보는 것이 좋습니다.
왜냐하면, 현재 풍부한 커뮤니티에서 지원했을 때 나온 기본 세팅이 가장 바람직할 가능성이 높기 때문이죠!

eslintrc.js

일단 override하는 방식으로 jest를 작성했군요.
이렇게 했을 때 해당 포맷에 맞는 파일들을 jest 환경에서 돌릴 수 있게 됩니다.

jest를 위한 설정은 preset으로 다음을 사용했습니다.
아무래도 타입스크립트와 바벨을 동시에 사용하기 편하게 지원해주는 것 같군요!

tsconfig.json

tsconfig,json에서는 다음과 같이 types로 jest와 webpack-env를 넣어주었군요.
다만 types를 직접 명시하여 설정하는 게 좋은지 아닌지는... 좀 따져봐야겠습니다.
아무래도 types를 직접 명시하는 경우에는 해당 타입만을 검사한다고 알고 있기 때문입니다.

이후에는 코드 컴파일 대상 경로들을 명시해주었네요!

나머지는 딱히 테스트 코드를 위해 작성된 건 없습니다.
추후 나중에 테스트 코드를 도입해야 할 대상이면, 해당 기본 세팅을 참고해도 좋지 않을까요!

이를 위해 해당 기본 세팅 버전 역시 남겨놓겠습니다.

{
  "name": "test",
  "version": "0.1.0",
  "private": true,
  "scripts": {
    "serve": "vue-cli-service serve",
    "build": "vue-cli-service build",
    "test:unit": "vue-cli-service test:unit",
    "lint": "vue-cli-service lint"
  },
  "dependencies": {
    "core-js": "^3.8.3",
    "vue": "^3.2.13",
    "vue-router": "^4.0.3",
    "vuex": "^4.0.0"
  },
  "devDependencies": {
    "@types/jest": "^27.0.1",
    "@typescript-eslint/eslint-plugin": "^5.4.0",
    "@typescript-eslint/parser": "^5.4.0",
    "@vue/cli-plugin-babel": "~5.0.0",
    "@vue/cli-plugin-eslint": "~5.0.0",
    "@vue/cli-plugin-router": "~5.0.0",
    "@vue/cli-plugin-typescript": "~5.0.0",
    "@vue/cli-plugin-unit-jest": "~5.0.0",
    "@vue/cli-plugin-vuex": "~5.0.0",
    "@vue/cli-service": "~5.0.0",
    "@vue/eslint-config-airbnb": "^6.0.0",
    "@vue/eslint-config-typescript": "^9.1.0",
    "@vue/test-utils": "^2.0.0-0",
    "@vue/vue3-jest": "^27.0.0-alpha.1",
    "babel-jest": "^27.0.6",
    "eslint": "^7.32.0",
    "eslint-plugin-import": "^2.25.3",
    "eslint-plugin-vue": "^8.0.3",
    "eslint-plugin-vuejs-accessibility": "^1.1.0",
    "jest": "^27.0.5",
    "lint-staged": "^11.1.2",
    "sass": "^1.32.7",
    "sass-loader": "^12.0.0",
    "ts-jest": "^27.0.4",
    "typescript": "~4.5.5"
  },
  "_id": "test@0.1.0",
  "gitHooks": {
    "pre-commit": "lint-staged"
  },
  "readme": "ERROR: No README data found!"
}

마치며

테스트 코드를 어느 정도 공부하고 있다가 다시 돌아와 세팅해보니 또 감회가 새롭네요.
제가 처음에 세팅했을 때와, 분명 다른 코드들도 존재하구요.
(저는 jest가 없는 환경에서 세팅한 터라, 좀 다르긴 합니다.)

또한, 테스트 코드를 선택할 때 막연히 커뮤니티가 많은 툴을 선택했는데, jest가 최선의 방안인지를 고민하게 된 좋은 경험을 하게 되었습니다.

일단 저는 혼자서 공부하는 터라 커뮤니티 활성도를 가장 중요시 하는 터라, jest를 시작으로 테스트 코드를 접해보려고 해요.
다만 나중에 규모가 커지면서 속도나 메모리에 부하가 생긴다면 적극적으로 다른 툴들도 탐색해보려 합니다.

그럼 즐거운 개발 하시길 바라며. 이상! 🌈

📘 참고자료

[stack
테스트 코드가 무겁고 느려진 이유