이상학의 개발블로그

[Node.js] Node + Mocha + Travis + Istanbul + Coveralls: 오픈소스 프로젝트 단위 테스트 & 코드 커버리지 (Unit tests & Code coverage) 본문

JavaScript/Node.js

[Node.js] Node + Mocha + Travis + Istanbul + Coveralls: 오픈소스 프로젝트 단위 테스트 & 코드 커버리지 (Unit tests & Code coverage)

학학이 2017. 7. 14. 00:25

NOTE : 
이 글은 Node + Mocha + Travis + Istanbul + Coveralls: Unit tests & coverage for your open source project를 한국어로 번역한 글입니다. 
블로그 배포 전에 원작자에게 동의를 구하고 번역 & 블로깅 했습니다. 
원본의 내용과 조금 다를 수 있고 필자의 정보가 추가됐습니다. 
또한, 단계별 과정에 캡쳐를 추가하고 코드를 Github 저장소에 올려 두었습니다.

This article is a translation of Node + Mocha + Travis + Istanbul + Coveralls: Unit tests & coverage for your open source project
Before publishing the blog, I asked for the authors’ consent and translated and blogged. 
The contents of the original may be slightly different, and my information has been added. 
I also added capture to the step-by-step process and put the code in the Github repository.

Introduction

Unit tests & code coverage metrics은 여러분이 오픈 소스 프로젝트를 더 쉽게 작업할 수 있게 도와준다. 
첫째로, 프로젝트 소유자인 당신이 프로젝트 안정성에 관심을 갖고 있음을 알려준다. 
둘째로, 프로젝트의 contributors들이 패치 버전에 대한 업데이트 요청(PR)을 자신 있게 보낼 수 있게 만들어준다. 
마지막으로, 프로젝트가 계속해서 오래 쉽게 개발될 수 있도록 도와준다.


Where to put your test files

https://github.com/SangHakLee/NMTIC/tree/01-Where-to-put-your-test-files

만약 테스트 파일이 오직 1개만 필요하다면, ./test.js라고 파일을 생성하면 된다. 
이것은 Mocha 모듈의 기본 파일 명명 규칙이다.


만약 테스트 파일이 여러 개로 나뉘어 있다면, test/ 폴더를 생성하고 index.js 파일에서 다른 테스트 파일을 호출해서 사용한다.


NOTE : 최근의 명명 규칙은 test/user.model.spec.js,test/user.ctrl.spec.js를 많이 사용한다. 
폴더 구조는 상관없으나, {}.spec.js로 spec이라는 단어를 중간에 넣어준다. 
명명 규칙이기 때문에 강제성은 없다. 일종의 규약.

만약 테스트 파일을 test/가 아닌 다른 곳에 놓아도, Mocha 실행 시 해당 경로를 지정해서 실행할 수 있다. 
그러나, 굳이 그럴 필요가 없기 때문에 기본 경로를 사용한다.


Get mocha to run your tests

https://github.com/SangHakLee/NMTIC/tree/02-Get-mocha-to-run-your-tests

Mocha 모듈이 설치되어 있지 않다면, 아래의 명령어로 모듈을 설치한다.

$ npm install -g mocha


아래의 명령어를 사용해서 기본 test 경로의 테스트 코드를 실행한다.

$ mocha


Write your tests

https://github.com/SangHakLee/NMTIC/tree/03-Write-your-tests

Mocha는 describe()와 it()라는 전역 변수로 테스트를 진행한다. 
추가적인 의존성을 줄이려면 Node.js의 기본 assert 모듈을 사용한다.

예시로 사용할 수 있는 단위 테스트 코드: dsernst/pythagorean-triples /test.js


Setup $ npm test

https://github.com/SangHakLee/NMTIC/tree/04-Setup-%24-npm-test

테스트 케이스를 수행하는 일반적인 방법은 npm의 기본 test 명령어를 사용하는 것이다. 
이를 위해서, "test": "mocha"를 package.json의 “scripts”에 추가한다.

package.json

"scripts" : {
"test" : "mocha"
}

$ npm test 를 입력하면 테스트가 진행된다.


또한, Mocha 모듈을 devDependency로서 추가하여 사용자가 $ npm install을 실행할 때마다 설치하게 할 수 있다.

$ npm install mocha --save-dev


Setup TravisCI for automatic builds

https://github.com/SangHakLee/NMTIC/tree/05-Setup-TravisCI-for-automatic-builds

Travis CI는 저장소에 Push 요청 시 코드를 자동으로 테스트하고 문제 발생 시 알람을 준다. 
Github의 Pull-Request 요청에도 작동하며 공개 저장소 사용 시 무료이다.

사용법:

  1. Travis CI에 로그인 후 사용을 원하는 저장소를 Switch-on 한다.


  1. .travis.yml 파일을 저장소에 추가한다.

    language: node_js
    node_js:
    - "stable"
  2. 코드를 Github에 Push한다.


Travis-CI가 Push 요청을 감지하면 자동으로 npm test 명령을 수행한다.


Get code coverage with Istanbul

https://github.com/SangHakLee/NMTIC/tree/06-Get-code-coverage-with-Istanbul

다양한 종류의 code coverage 분석 툴이 있지만, istanbul을 사용한다.

NOTE : Code coverage란, 테스트 케이스가 소스 코드를 얼마만큼 테스트했는지 알려주는 지표이다. 
높은 Code coverage일수록 모든 경우의 수를 테스트했다고 신뢰할 수 있다. 
즉, 작성한 단위 테스트 케이스들이 모든 소스 코드를 다 수행했는지 알려주는 지표다.


먼저, istanbul을 devDependency로 설치한다.

$ npm install istanbul --save-dev

코드 커버리지를 위한 npm run-script를 작성한다.

package.json

"cover": "node_modules/.bin/istanbul cover ./node_modules/mocha/bin/_mocha"

NOTE : 원본 글에 "cover": "istanbul cover _mocha"라고 명시되어 있지만, 필자의 환경에서는 작동을 안 했다. 실행 경로가 제대로 잡히지 않았던 것 같다. 
따라서 위와 같이 직접 node_modules이 설치된 binary 경로를 명시해서 사용했다.


이제 package.json에 두개의 실행 스크립트가 존재한다. 
package.json

"scripts": {
"test": "mocha",
"cover": "node_modules/.bin/istanbul cover ./node_modules/mocha/bin/_mocha",
},


여기서 한 가지 이상한 점이 있는데, mocha 대신 _mocha를 사용했다. 
mocha 프로세스는 child process로 실행되기 때문에 그냥 사용하면 istanbul이 아래와 같은 에러를 던진다.

No coverage information was collected, exit without writing coverage information

그러나, _mocha로 사용하면 child_process 없이 실행하기 때문에 아래와 같은 코드 커버리지 결과를 얻을 수 있다.

  • Statements: 코드의 Statements(명령문)의 수행률
  • Branches: 코드의 Branches(분기문, if-else, switch 등)의 수행률
  • Functions: 코드의 Functions(함수)의 수행률
  • Lines: 코드의 Lines(코드 수)의 수행률

코드 커버리지만 원하면 아래와 같은 명령어를 입력하면 된다.

$ npm run cover


Adding automatic coverage testing with Coveralls

https://github.com/SangHakLee/NMTIC/tree/07-Adding-automatic-coverage-testing-with-Coveralls

Coveralls은 공개 저장소에 사용할 수 있는 또 다른 서비스이다. 
이것은 코드 커버리지 결과를 공개적으로 보고하면서 Travis-CI를 보완한다. 
또한, 커버리지 결과가 큰 폭으로 변하는 경우 사용자에게 알리도록 구성할 수 있다.

  1. Coveralls.io에서 계정 생성 후 사용할 저장소를 선택한다.


  1. 아래의 npm 모듈을 설치한다.

    $ npm install --save-dev coveralls mocha-lcov-reporter
  2. 다음과 같이 package.json에 추가한다. istanbul의 결과를 Coveralls로 연결한다.

    "coveralls": "npm run cover -- --report lcovonly && cat ./coverage/lcov.info | coveralls"
  3. .travis.yml에 다음과 같이 추가한다. 빌드가 성공한 후에 coveralls 명령 스크립트를 실행한다.

    after_success:
    - npm run coveralls
  4. 소스 코드 수정 후 Push를 해보자.


이제 Travis-CI에서 빌드가 성공할 때마다, 업데이트된 코드 커버리지가 Coveralls로 보내진다. 


$ npm run coveralls 명령어를 사용해서 Coveralls을 갱신할 수 있다. 물론, .coveralls.yml 파일이 해당 저장소에 있어야 한다. 이 떄는 .gitignore.coveralls.yml을 추가해야 안전하게 이용할 수 있다. (Key 정보가 들어가기 때문에)


Success

https://github.com/SangHakLee/NMTIC/tree/08-Success

이 모든 과정을 설정했다면, 이제 프로젝트에 build status, code coverage 뱃지를 README.md에 추가할 수 있다.


이로써 저장소를 watching하고 있는 사용자들에게 프로젝트가 책임감 있게 관리되고 있음을 알려줄 수 있다.

Conclusion

https://github.com/SangHakLee/NMTIC

처음에 Travis-CI, Coveralls에 관심을 갖게 된 이유는 단순했다. 나도 다른 오픈소스처럼 멋진 뱃지를 README.md 넣고 싶었다. 두 서비스를 쓰다 보니 자연스럽게 TDD로 개발하는 방법을 익히게 됐다. 
Build status와 Code coverage report가 나와있는 오픈소스는 다른 사람들이 보기에도 신뢰를 준다. 
더 멋진 오픈소스 저장소를 위해서 써보는 것을 적극 추천한다.


Comments