출처: http://webframeworks.kr/tutorials/nodejs/api-server-by-nodejs-04/


*Mocha
노드에서 가장 유명한 테스트 툴은 Mocha이다.
Mocha 테스트 코드를 구동시켜주는 테스트 러너이다.Mocha역시 노드로 작성된 패키지중 하나로 npm으로 설치 가능

$ npm i mocha —save-dev

—save-dev 옵션은 개발환경을 위한 패키지 의존성을 설정하기 위한 것이다. 명령을 실행하고 나면 package.json devDependencies속성에 모카 설치정보가 추가된다.


  • 패키지파일의 의존성에 대해
    npm
    프로젝트에 사용되는 노드 패키지 모듈들을 모두 package.json 기록한다.
    대부분은 dependencies 속성에 패키지명과 버전이 적힌다. 서버에 코드를 배포한뒤 서버에서 npm install —production 으로 노드 패키지들을 설치하게 되는데 이때 노드는 package.json dependencies 참고해서 여기에 있는 것들을 설치한다.

    그럼 devDependencies 언제 사용할까?
    ->
    이것은 순전히 개발자를 위한 정보이다. 코드를 서버에 배포하지 않고 다른 개발자가 코드를 코드 저장소에서 다운로드했을
    개발자는 npm install 필요한 노드 패키지를 설치한다. 이때 노드는 똑같이 dependencies속성에 있는 패키지들을 설치한다.
    그리고 —production 없기 때문에 devDependencies속성에 있는 패키지들도 추가로 설치하는 것이다.

    다시 모카로 돌아와서
    테스트 코드는 test suite test 구분할 있다. 수트는 테스트들을 모아놓은 하나의 환경이라고 생각하면 되고, 테스트가 실제 테스트를 수행하는 코드이다.
    모카에서는 각각 describe() it()함수로 기능을 제공한다.
    -describe():
    테스트 수트
    -it():
    테스트
    함수를 이용하여 테스트 코드를 작성해보자. User API 대한 테스트 코드는 api/users/user.spec.js 작성한다.(보통 파일명에 spec이라는 단어가 들어가면 테스트 코드이다.)


모카로 작성한 테스트 코드는 기본적으로 이러한 구조를 가짐.
describe()
함수의 첫번째 파라미터로 테스트 수트의 설명을 서술형 문자열로 넣고 

두번째 파라미터로 함수를 입력함. 비동기 로직의 콜백 형식으로 넣는 것이다.

안에는 it()함수를 이용해 실제 테스트 코드를 작성한다.

설치한 모카 패키지는 node_modules폴더에 있음 npm 패키지 중에 실행 파일이 있는 경우 모두 node_moules/.bin 폴더에 링크된 파일이 위치한다. 여기에 저장된 mocha 명령어를 이용해서 테스트를 실행한다.

$ node_modules/.bin/mocah api/users/user.spec.js


npm start 사용했던것 처럼 npm test 대한 스크립트를 package.json  추가해서 테스트 명령어를 간편하게 한다.


package.json




*Should

이번에 추가할 것은 검증 로직이다. describe(), it() 이용해서 테스트를 작성했지만 진짜 테스트 코드( 결과가 맞는지 확인) 아직 없음. 노드 기본 모듈중 assert 모듈을 이용해 보자.


assert모듈의 equal()함수는 개의 파라미터를 받는데 값이 같은 경우 지나가고 그렇지 않을 경우 에러를 던진다. npm test 이용해 테스트를 실행해보자.


assert.equal() 실행결과 에러를 던지면서 모카에서는 위와 같은 결과를 리포팅 한다. 만약 테스트가 통과한다면 성공 메세지를 보여준다.



assert 노드 기본 모듈이긴 하지만 테스트에서는 이것 말고 다른 모듈을 사용하라고 . 노드 공식 페이지에서 그렇게 이야기하고 있음.

가장 많이 쓰는 모듈중 하나가 should이다. 이것은 서술식의 검증을 코드로 작성할 있게해줌.(코드 쓰는게 마치 서술식 문장같음)


$ npm i should —save-dev



(true) 같은가(should be equal) (true)



*supertest

마지막으로 api  테스트를 가능하게 해주는 노드 패키지가 있는데 바로 supertest이다. supertest 우리가 만든 express 서버를 구동한 http요청을 보내고 응답받는 구조인데 응답을 should 검증하면 되는 것이다.


supertest 설치한다.


$ npm i supertest —save-dev


supertest 사용하려면 서버 역할을 하는 express객체를 가져와야 한다. supertest 실행 함수 파라미터로 사용하기 위함이다. app.js파일에서 우리가 만든 app변수를 외부 노출하여 모듈로 만들어 줘야하는데 module.exporets 키워드로 app 노출해 주면 된다.


//…

module.exports = app;


이제 테스트 파일인 api/users/user.spec.js파일에서 모듈을 가져와 슈퍼테스트와 결합해 사용해 본다.




실행할때 원래 켜져있는 서버가 있으면 안된다. 테스트와 동시에 서버 실행이기 때문이다.


request 상수에 슈퍼테스트 모듈을 할당했음. 그리고  app모듈을 request() 함수의 파라미터로 넣었는데 이것은 우리가 만든 express  서버인 app 슈퍼테스트로 테스트하겠다는 의도이다.


슈퍼테스트는 함수 체이닝을 이용해 get()함수로  api요청을 보낸다. expect()함수로 응답 코드를 설정한 실제 요청을 보내고 응답되면 end()함수에 파라미터로 넣은 콜백함수가 동작하게 되는 구조이다. 콜백함수는 err res  개파라미터를 받는데 요청에 실패하면 err 객체가 활성화되고 그렇지 않으면 res.body 통해 응답 바디에 접근할 있음. 여기서는 api 상태코드 200 리턴하는가만 체크하는 코드이다.

그리고 마지막에 done()함수를 호출 했다. 이것은 it()함수의 두번째 파라미터인 콜백함수의 파라미터인데 슈퍼테스트가 http요청을 하는 비동기 로직이기 때문에 모카측에서 it()함수가 종료되는 시점을 알기위해 사용되는 함수이다.


바디를 점검하는 코드이다.



should.be.an.instanceof() 함수를 이용해 응답 바디의 타입이 배열인지 체크했다. 그리고 함수 체이닝을 이용해 배열의 길이가 3인것을 확인했음.


다음 코드는 res.body 배열임을 확인했으므로 배열 메소드인 map() 이용해 배열의 요소를 점검한다. 배열의 요소 user id name프로퍼티를 가지고 있고 가각 숫자형, 문자형임을 확인했음.


모든 검증을 마치면 모카에게 it()함수가 종료됨을 알리는done()함수를 호출하고 테스트를 종료한다.

이와 같은 형태로 나머지 api(get, post, /users/:id ) 테스트코드를 작성하도록 하자.


test-driven development https://github.com/kiryun/NodeJS_REST-API_tutorial 이곳에 올려놨다.


+ Recent posts