테스트 주도 개발 패턴
TDD (Test Driven Development)
한글로 하면 테스트 주도 개발 이라는 뜻이다. 보통 우리의 업무 프로세스는 개발을 하고 개발한 결과물에 관한 테스트를 진행하게된다. 유닛테스트, 통합테스트, 종단간 테스트 등.. 그런데 TDD는 개발하기 전에 실패하는 테스트를 만들고, 테스트의 오류를 해결해나가면서 성공적인 테스트를 완성하는데 중점으로 개발을 진행한다.
장점
꼼꼼히 개발할 수 있다- 테스트를 먼저 만듬으로서 빠지는 요소없이 확인하면서 개발은 진행할 수 있다.목표가 명확하다- 우리는 개발하다보면 길을 잃을 때가 꽤나 많다. 어떠한 기능을 개발하다가 다른 사이드 이펙트가 생겨 본래 개발목적과 다른 곳에 시간을 쓰는 경우도 있고, 내가 개발을 하다보면 지금 의미있는 코딩을 하는건가? 라는 의심이 생기는 경우가 있다. 그런면에서 TDD는 테스트로 먼저 목적을 작성하기 때문에 테스트의 초록 막대를 뜨게 만들면 되는 간단한 목표가 명확하게 있다.의사 소통의 편리함을 가질 수 있다- 어떠한 코드를 설명할 때 간단하게 테스트를 보여줌으로 (물론 목적이 정확히 명시되어있는 잘 짜인 테스트 코드를 한 해서) 내가 주절주절 설명할 필요없이 원하는 결과를 유추할 수 있게 할 수 있다.두려움을 관리할 수 있다- 우리는 개발하기 전에 많은 상상을한다. “이렇게 짜면 나중에 문제가 될텐데?” 라고 생각하는 경우나 어떤 큰 기능을 만들기 전에 의욕이 안나고 어떻게 만들어야 할지 감이 안올 때 테스트를 먼저 만들면 조금 더 작은 단위로 생각할 수 있게된다. 그래서 우리는 어려운 코드를 짤 때 상황을 제어할 수 있게된다.리팩토링- 테스트 코드를 수월하게 짜기 위해선 자연히 커플링이 줄어들고, 디커플링을 지향하는 코드를 작성하게 된다. 그리고 테스트 코드를 통해 어떠한 기능이 중복되는지 확인하고 추상화할 수 있어 리팩토링면에서도 장점이 있다 생각한다.
유지보수나 개선 사항에서도 장점이 있을 수 있지만… 먼저 위의 생각은 본인의 생각이며 더 많은 장점이 있을 수도있고, 위의 장점이 다른 사람에겐 다르게 적용할 수도 있다.
단점
테스트 코드를 짜야된다- 테스트 코드를 아예 안 짜봤던 사람은 처음에 테스트 코드를 어떻게 짜야할지 감이 잘 안오게 된다. 어떠한 범위부터 적어야 하는지 작은 것도 테스트가 하는게 맞는지 등 처음 시작할 때 어려움을 겪을 수 있으며, 바쁜 상황에 구현하기도 바쁜데 테스트 코드를 짜라고 하면 황당할 수 있다.기획이 안되어 있을 때- 정확하게 구현할 목적이 정해져 있지 않고, 상황에 따라 계속 구현이 바뀌는 경우에는 TDD를 적용하기 쉽지않다. TDD는 본인이 구현할 범위나 기능등을 어느정도 산정하고 진행해야 의미있는 TDD를 만들 수 있다.본인이 완벽할 때- 테스트는 본인이 만든 프로그램에 대한 의심이다. 본인이 완벽하면 굳이…? 근데 자신있게 본인이 완벽한 코딩을 한다고 말할 수 있는 사람이 있긴할까 싶다.
TDD 프로세스
1. 테스트 작성
TDD의 모든 시작은 테스트를 작성하면서 시작하게 된다. 간단한 예제로 더하기를 하는 jest를 사용한 테스트코드는 아래와 같다.
1
2
3
test("1 plus 2", () => {
expect(plus(1, 2)).toBe(3);
});
2. 테스트 실패확인
위와 같이 테스트를 작성하고 npm run test를 실행해보면 (설정이 필요하지만 이건 TDD에 대한 포스팅이니 생략하겠다.)
plus가 구현된게 없으니 당연히 위와 같이 당연히 실패한다.
그러면 우리가 할 일은 명확하다 plus를 구현하면 된다.
3. 코드 구현 / 수정
아래와 같이 코드를 작성해 준다.
1
2
3
export function plus(addend: number, augend: number) {
return addend + augend;
}
4. 테스트 재실행
그리고 다시 테스트를 실행하면 아래와 같이 성공처리가 된다!
5. 중복제거(리팩토링)
이 과정을 이렇게 간단한 plus 함수가 아닌 복잡한 비즈니스 로직을 구현하다 보면 중복이 되는 경우가 많이 생기게 된다.
그러면 중복을 제거하고 리팩토링을 한다.