week4 tech from

4주차 기술 공유

작성자 : 김희선, 서보현

testing

socket.io test

• 필요한 이유: 현 상황에서 api도 없고 앞으로도 거의 안생길것. socket을 테스트하지 않으면 테스트할만한 코드가 없다.
• socket.io 테스트 하는 법: server test를 하기위해 test코드에서 클라이언트를 만든다. 그 클라이언트로 서버에 접속한다. connect 이벤트부터 테스트한다. test할 때 다 listener에 들어오는지 확인해야하기 때문에 callback함수 안에 done()을 써줘서 정확히 테스트한다. api 테스트처럼 socket도 emit과 on이 바로 일어나는 이벤트들을 테스트할 수 있다. on을 먼저 달아주고 그에 해당하는 event를 emit한다.

jest

jest란?

• All-in-one 테스팅 라이브러리이다. Jest 이전에는 자바스크립트 코드를 테스트하라면 여러가지 테스팅 라이브러리를 조합해서 사용하곤 했었다. 하지만 Jest는 라이브러리 하나만 설치하면, Test Runner와 Test Mathcher 그리고 Test Mock 프레임워크까지 제공해주기 때문에 상당히 편리한 것 같다.

jest 사용하기

1. jest 라이브러리 설치하기

   npm i -D jest
   

2. test script 수정하기

   • package.json 파일을 열고 test 스크립트를 jest로 수정한다.

   "scripts": {
     "test": "jest"
   },
   

   • 그리고 여기에 주고 싶은 option을 추가할 수 있다.

3. 테스트 코드 작성하기

   • test / it : 테스트 하나를 작성할 때 사용하는 키워드이다.(하나의 테스트 단위) 아래는 예시이다.

   test('socket connect test', (done) => {
       socket.on('connect', () => {
         done();
       });
   });
   

   • describe : describe 라는 키워드를 사용하여 여러 테스트 케이스를 묶을 수 있다.

   describe('socket.io test', () => {
     beforeAll(() => {
       ...
     });
   
     afterAll(() => {
      ...
     });
   
     test('socket connect test', (done) => {
       ...
     });
   
     test('[EMIT] \'enter_room\' event test', (done) => {
       ...
     });
   });
   

jest 더 알아보기

• 아래의 Methods들은 모두 scope가 있다. 전역에 쓰면 모든 테스트에 적용되고 하나의 describe안에 넣으면 그 describe안에 있는 test에만 적용된다. 예시는 위의 코드와 같다.
• afterAll(fn, timeout): 모든 테스트가 끝나고 한번 실행된다.
• afterEach(fn, timeout): 하나의 테스트가 끝날 때 마다 매번 실행된다.
• beforeAll(fn, timeout): 모든 테스트가 시작하기 전에 한번 실행된다.
• beforeEach(fn, timeout): 하나의 테스트가 시작하기 전에 매번 실행된다.

자주 사용되는 Matcher

• toEqual(): 두 값이 같은지 비교하는 Matcher이다. object가 정확히 같은지 판단할 수 있다. javascript에서 ===와 같다.

  expect(response).toEqual(value);
  

• toBeTruthy(), toBeFalsy(): 값이 false인지 true인지 확인하는 Matcher이다.

  expect(response).toBeTruthy(); // response가 true인지 확인
  

• toHaveLength(): object의 길이를 확인하는 Matcher이다.

  expect(response).toHaveLength(3);
  

• toContain(): array에 포함하는지 확인하는 Matcher이다.

  expect(response).toContain('hello');
  

• toThrow(): 에러를 throw()하는지 확인하는 Matcher이다.

  expect(() => {
      drinkFlavor('octopus');
  }).toThrow();
  

JSdoc 사용과 자동 문서화

• 결과 : 문서화 페이지

JSDoc이란?

• JSDoc은 Javascript를 위한 API 문서 생성기이다. 소스코드에 직접 문서화 주석을 작성하고, JSDoc에서 이를 탐색해 HTML 문서를 제공한다.

VSCode JSDoc support

• VS Code는 다양한 JSDoc 주석을 이해하고, 이 주석을 Intellisense에게 제공한다. 그에 따라 Javascript에서도 type 정보를 볼 수 있다. 따라서 코드 작성시 type check를 할 수 있다.
• 실제 팀프로젝트 코드에 작성한 JSDoc 주석

  /**
  * @param {number} newIndexX
  * @param {number} newIndexY
  * @returns {Boolean} 움직임이 가능한지 여부
  */
  _canBeMoved(newIndexX, newIndexY) {
    if (newIndexX < 0 || newIndexX >= ROOM.FIELD_COLUMN) return false;
    if (newIndexY < 0 || newIndexY >= ROOM.FIELD_ROW) return false;
    if (this.indexOfCharacters[newIndexX][newIndexY] !== undefined) return false;
    return true;
  }

• 결과

documentation.js

• 역시 JSDoc을 이해하는 API 문서화 시스템이다.

• JSDoc은 주석 형식을 의미하고, JSDoc을 이용해서 자동으로 문서를 생성해주는 라이브러리는 별개라고 생각해서 찾아보다가 documentation.js를 사용해주기로 했다. (참고 링크 : https://meetup.toast.com/posts/208)

  • 위 링크에서 언급한 documentation.js의 장점들은 다음과 같다.

  • ES5, ES2017, JSX, Vue, Flow 타입을 지원한다.
  • JSDoc 파싱 데이터를 마크다운, JSON으로 제공한다.
  • 노드 환경에서 사용할 수 있는 사용자 API를 제공한다.
  

• serve, watch 등 편리한 CLI 명령들도 지원해준다.

•   $ documentation build index.js -f md
    $ documentation build src/** -f html -o docs/apidocs
  
    # document index.js, ignoring any files it requires or imports
    $ documentation build index.js -f md --shallow
  
    # build and serve HTML docs for app.js
    $ documentation serve app.js
  
    # build, serve, and live-update HTML docs for app.js
    $ documentation serve --watch app.js

• 문서화 결과

JSDoc + VSCode + documentation.js

• 게임 내 모델의 메소드들이 많아지고, 로직이 복잡해지면서 인자로 받는 값의 개수와 타입, 반환하는 값이 있는지 있으면 타입은 무엇인지 등을 알기가 어려워진다.

  • 

• Jsdoc을 작성해주면 한 곳에서 작성한 함수를 다른 곳에서 사용할 때도 받아야 하는 인자와 반환하는 값이 무엇인지 등을 알 수 있는 장점이 있었다.

• 거기에 더해 documentation.js를 사용해 현재 팀 내에서 사용하고 있는 모델과 모델이 갖고 있는 메소드들을 쉽게 문서화해서 볼 수 있게 됐다.

• 프로젝트가 커질수록 이런 방식은 유용할 것 같다. 그리고 현재 프로젝트에서 메소드들은 많지만, 받는 인자등은 그렇게까지 복잡하지 않아서 JSDoc을 최대 활용하고 있지는 않은 것 같다.

• 단, TypeScript를 사용한다면 type check를 하기 위해서 JSDoc을 사용하는 일은 없지 않을까 생각한다.