오늘은 그동안 강의 결제만 하고 잠시 잊고 있던 TDD 강의를 들었다.
이규원의 현실 세상의 TDD : 안정감을 주는 코드 작성 방법 이라는 강의를 보고 TDD가 과연 무엇인가, 사용하면 뭐가 좋나, 특징은 뭘까에 대해 정리를 했다.
TDD❓
TDD란 Test-Driven-Development의 약자로 '테스트 주도 개발' 이라고 한다.
반복 테스트를 이용한 소프트웨어 방법론으로, 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현한다.
기존 개발 프로세스와 달리 실제 코드를 작성하기 전에 테스트 케이스를 먼저 작성하여 개발자가 무엇을 해야 하는지를 명확히 한다.
단위 테스트 - Unit Test
하나의 모듈을 기준으로 독립적으로 진행되는 가장 작은 단위의 테스트이다.
TDD 개발 주기
위 그림은 개발 주기를 표현한 것이다.
- RED 단계에서는 실패하는 테스트 코드를 먼저 작성한다.
- GREEN 단계에서는 테스트 코드를 성공시키기 위한 실제 코드를 작성한다.
- BLUE 단계에서는 중복 코드 제거, 일반화 등의 리팩토링을 실시한다.
여기에서 중요한 점은 RED 단계에서 실제 코드를 작성하지 않는 것이다.
TDD 개발 장점
- 보다 튼튼한 객체 지향적인 코드 생산
- 재설계 시간의 단축
- 디버깅 시간의 단축
- 테스트 문서의 대체 가능
- 추가 구현의 용이함
이런 장점이 있는데도 TDD 개발을 하지 못하는 이유
- 이제까지 자신이 개발하던 방식을 많이 바꿔야 한다.
- 체득한 것이 많을 수록 바꾸기가 어렵다.
- 오히려 개발을 별로 해보지 않은 사람들에겐 적용하기가 쉽다.
- TDD는 이렇게 해야된다는 이미지/틀이 있다.
- 반드시 툴을 써서 개발해야 된다고 생각한다.
- 이러한 규칙에 얽매이는 것은 애자일 방식이 아니다.
- 결국엔 규칙에 얽매여 똑같은 테스트를 복붙한다.
- 도구/규칙에 집착하다 보니, TDD가 어려워진다.
회고
그동안 나는 TDD 방식으로 개발을 하지 않았다. 어떻게 해야 하는지도 몰랐었고, 뭔가 많은 테스트를 짜게 되면 더 시간이 오래 걸리게 되지 않을까 하는 걱정 때문에 망설였다.
그리고 테스트 코드를 짜보긴 했지만 돌이켜봤을 땐 테스트라는 개념을 이해하지 못하고 그냥 테스트라는 목적으로 그럴싸한 코드를 작성했던 것 같다.
아무튼 이제라도 한번 TDD 방식을 따라봐야겠다. 처음엔 익숙하지 않아서 어려울 것 같지만 계속 쓰다보면 익숙해지지 않을까 생각한다.
백엔드 개발자