TDD?
Test-Driven Development. 줄여서 TDD.
말 그대로 테스트가 개발의 주체가 되는 개발 방법으로, 테스트를 먼저 작성하고 그 테스트를 통과하는 코드를 나중에 작성하는 방법론이다.
한때 배달의 민족의 어떤 팀에서 TDD를 강조한다는 사실이 알려져서 TDD가 엄청난 이슈로 떠오르기도 했었다.
TDD의 개발 주기
그렇다면 TDD의 개발은 어떤 식으로 진행될까?
🟥실패하는 테스트 코드를 먼저 작성한다.
🟩테스크 코드를 성공시키기 위한 실제 코드를 작성한다.
🟦중복 코드 제거, 일반화를 통한 리팩토링을 수행한다.
큰 틀은 다음과 같이 진행된다.
이때 중요한 것은 실패하는 테스트 코드를 작성할 때까지는 실제 코드를 작성하지 않아야 되고, 실패하는 테스트를 통과할 정도의 최소 실제 코드를 작성해야 한다.
그렇다면 TDD는 좋은걸까?
분명 장점이 있으니까 쓰는 사람이 생겼고, 하나의 유행처럼 번지지 않았을까 생각한다.
일단 TDD의 장점은
- 완성도 높은 설계
TDD는 테스트 코드를 먼저 작성하기 때문에 무엇을 해야하는지 분명히 정의하고 개발을 시작하게 된다. 또한 테스트를 작성하면서 다양한 예외상황에 대해 생각해 볼 수 있으므로 완성도 높은 설계를 하게 된다.
- 튼튼한 객체지향적인 코드
TDD는 코드의 재사용성을 보장할 것을 명시하므로 철저한 모듈화가 이루어진다. 따라서 종속성과 의존성이 낮은 모듈로 조합된 소프트웨어 개발이 가능하며, 필요에 따라 모듈을 추가하거나 제거해도 소프트웨어 전체 구조에 영향을 미치지 않는다.
- 디버깅 시간 단축
TDD에서는 유닛 테스트를 진행한다. 따라서 버그가 발생한다면 어디에서 발생하는 버그인지 바로 알아차릴 수 있다.
- 테스트 문서 대체 가능
보통 작성하는 테스트 정의서는 단순 통합테스트 문서에 지나지 않는다. 즉, 내부의 로직들이 어떻게 테스트 되는지 알 수 없다는 소리다. 하지만 TDD를 하게 될 경우 테스팅을 자동화 시킴과 동시에 보다 정확한 테스트 근거를 산출할 수 있다.
- 추가 구현의 용이함
개발이 완료된 소프트웨어에 어떤 기능을 추가할 때 가장 우려되는 점은 해당 기능이 기존 코드들에 어떤 영향을 미칠지 모른다는 점이다. 따라서 단순한 기능이라도 추가 된 후에는 모든 기능들을 처음부터 테스트 해야한다. 하지만 TDD의 경우 자동화된 유닛 테스팅을 전재하므로 이러한 테스트 기간 역시 획기적으로 단축시킬 수 있다.
TDD는 이렇게 좋은 장점들을 가지고 있다.
하지만 TDD를 따르지 않는 사람들도 분명 많다. 왜 그럴까?
TDD의 단점
- 생산성 저하
TDD 방식의 개발 시간은 일반적인 개발 방식에 비해 대략 10~30% 정도로 늘어난다. 처음부터 2개의 코드를 짜야하고, 중간중간 테스트를 하면서 고쳐나가야 하기 때문이다.2.학습의 어려움
기존 방식으로 개발을 하던 사람들은 TDD를 익히기 어렵다.
- 테스트 코드에 매몰된다.
개발을 잘하기 위해 TDD를 하는 것인데, TDD에 미숙하다면 테스트코드를 통과하는 코드를 짜는 것에만 집중하게 된다.
그렇다면 나의 의견은?
사실 나는 잘 모르겠다. TDD에 대한 찬성, 반대 의견을 내세울만큼 TDD를 잘 알지 못한다.
그럼에도 굳이 입장을 정한다면, 찬성쪽에 서고 싶다.
테스트 코드를 먼저 작성한다면
시니어 입장에서는 주니어 개발자를 리드하기에 편할테고,
주니어 입장에서는 테스트 코드를 따라 개발하면 되니까 개발하기 좀 수월할 테니까?
