TDD(Test-driven development)

1571min·2020년 7월 6일
0

FINAL 프로젝트

목록 보기
3/4

이번 프로젝트에서 TDD(Test-driven development) 방식을 도입했었다 나는 트랙과 스케쥴에 관한 API를 TDD로 진행하기로 하고 먼저 테스트 작성에 들어갔다

API 테스트를 작성하기 위해 supertest모듈을 사용하였다
https://www.npmjs.com/package/supertest
supertest 모듈에 대해서 간략하게 설명하면 테스트 파일 안에서 API 테스트를 하기 위해서 서버를 작동시켜야 하는 불편함이 있는데 supertest의 경우 그 과정을 좀더 간결하게 도와주는 모듈이다 사용법은 아래와 같다

설치

npm install supertest --save-dev

사용법

import * as request from 'supertest';
import * as express from 'express';
 
const app = express();
let agent = request(app);

describe('GET /user', function() {
  it('responds with json', function(done) {
    agent
      .get('/user')
      .set('Accept', 'application/json')
      .expect('Content-Type', /json/)
      .expect(200, done);
  });
});

테스트를 얼추 작성하고 테스트를 실행하였는데 Mocha를 Typescript에서 찾지를 못해서 그래서 구글링 결과 아래와 같이 실행 시켜주면 실행이 가능했다

node_modules/.bin/mocha -r node_modules/ts-node/register src/__test__/tracks.test.ts

supertest session연동

테스트에서 user의 정보를 이용한 테스트가 존재하였는데 user의 정보가 session에 담겨있었기 때문에 이를 해결하기 위해 여러가지 방법을 찾았었다 처음에는 모든 테스트 이전에 beforeEach를 이용하여 로그인 요청을 날려주고 테스트를 진행하였는데 session이 유지가 안되는 버그가 있었다 아마 이를 해결하기 위해서 모든 테스트를 로그인 promise then 안에서 처리를 해줘야 될 것 같다는 느낌을 받았는데 이미 다른 테스트를 작성한 뒤에 유저 테스트가 추가되는 바람에 다른 방법을 찾다가 supertest-session 모듈을 발견하였다
https://www.npmjs.com/package/supertest-session

해당 모듈은 beforeEach를 이용해서 로그인을 진행하여도 session을 유지할 수 있는 모듈이다 사용법은 supertest의 superset같은 모듈이라 사용방식은 비슷하다

session문제를 해결하고 아래와 같이 테스트를 작성하였다(트랙 테스트의 일부분)

describe('ModueRun - Server tracks API test', () => {
  beforeEach((done) => {
    agent.post('/users/signin')
      .send({ email: 'test@gmail.com', password: '1234' })
      .expect(200)
      .end((err) => {
        if (err) return done(err);
        return done();
      });
  });
  after((done) => {
    app.close();
    console.log('테스트 끝');
    done();
  });
  describe('GET /tracks', () => {
    const userPosition = {
      latitude: 37.202246,
      longitude: 127.114184,
    };
    const area = {
      latitude: 37.206755,
      longitude: 127.107272,
      latitudeDelta: -0.010504,
      longitudeDelta: 0.020504,
    };
    it('it should return filtered track list when maxLength filter on', async () => {
      const filter = {
        maxLength: 500,
        distance: -1,
        rate: false,
        recent: false,
      };
      const url = `/tracks/${JSON.stringify(filter)}/${JSON.stringify(userPosition)}/${JSON.stringify(area)}`;
      const response = await agent.get(url);
      expect(response.body).to.deep.equal([
        TrackSeed.test[0],
        TrackSeed.test[1],
        TrackSeed.test[3],
      ]);
    });
  });

TDD를 하면서 느낀점

장점

테스트를 작성하고 개발에 들어갔을 때 느꼈던 점은 테스트를 통해 계속 피드백을 받을 수 있었고 이를 통해 내가 작성한 코드에 대한 신뢰감을 얻을 수 있다 단순한 한 두번에 단위 테스트가 아닌 트랙 서비스에 대한 모든 테스트를 작성하였기 때문에 유틸을 따로 작성해서 테스트할 때도 여러가지의 경우의 수를 체크할 수 있었다

예를 들어 필터의 관한 유틸을 작성해야 했을 때 해당 필터 유틸을 가져다 쓰는 모든 요청을 한번에 테스트할 수 있다는 것은 생산성 면에서도 굉장히 좋다는 느낌을 받았다
이는 자연스럽게 유지보수에 대한 피드백도 테스트를 통해 받을 수 있게 도와주었다
마지막으로 TDD는 에러 핸들링 처리를 수월하게 해준다 API 작성 후 각각의 에러에 대한 환경설정과 하나하나 요청과 상태 코드를 확인하는 것은 매우 비효율적인 일 일수밖에 없다 이런 과정을 테스트에 모두 작서하여 놓으면 매번 반복적인 과정을 생략할 수 있게 된다.

단점

위와 같은 장점은 어느 정도 테스트를 제대로 작성하였을 때 가져갈 수 있는 장점인 것 같다 사실 이번 프로젝트에서는 테스트를 작성하고 코드를 작성하다 다시 테스트로 가서 수정하는 일이 빈번하였고 이를 통해서 테스트를 꼼꼼하게 작성해야겠다는 생각도 들었다 그리고 초반에 테스트를 처음 작성하는 나로써는 테스트 작성방식을 학습하는 시간도 소요되었다

profile
데이터에 소외된 계층을 위해 일을 하는 개발자를 꿈꾸는 학생입니다

0개의 댓글