개발 방법론, 왜 필요할까?
코드를 작성하는 일은 생각보다 복잡하다. 고객이 원하는 기능을 만들어야 하고, 팀원들과 함께 일해야 하며, 버그 없이 잘 동작하는지 확인도 해야하고, 정해진 시간 안에 완성해야한다.
이렇게 많은 것들을 한번에 신경 쓰다 보니 실수가 잦아질 수밖에 없었고, 이를 해결하기 위해 개발 방법론이 등장하게 되었다고 한다.
개발 방법론을 사용하면 여러 가지 장점이 있다. 프로젝트가 언제 끝날지, 어떤 결과물이 나올지 미리 예측할 수 있고, 체계적으로 일하다 보니 실수도 줄고 더 좋은 프로그램을 만들 수 있다. 또한 팀원들이 같은 방식으로 일하기 때문에 협력이 더 쉬워지고, 문제가 커지기 전에 미리 발견하고 해결할 수 있다는 장점도 있다.
TDD(Test Driven Development)란
TDD는 1990년대 후반 Kent Beck이 Extreme Programming의 일부로 개발한 기법이다.
전통적인 개발 방식이 “구현 → 테스트” 순서였다면, TDD는 “테스트 → 구현 → 리팩토링”이라는 반복적인 주기로 개발을 진행한다.
테스트 케이스 목록 작성
TDD의 핵심 사이클은 Red-Green-Refactor로 요약되지만, “리팩토링”의 저자인 마틴 파울러는 먼저 테스트 케이스의 목록을 작성하는 것을 강조한다. 이 단계에서는 다음 내용을 수행한다.
- 구현하고자 하는 기능의 테스트 케이스들을 미리 나열한다.
- 설계의 핵심 포인트를 빠르게 도출할 수 있는 순서로 테스트를 배치한다.
- 개발 과정에서 새로운 테스트 케이스를 지속적으로 추가한다.
TDD의 핵심 사이클 (Red-Green-Refactor)
1. Red 단계: 실패하는 테스트 작성
- 구현하고자 하는 기능의 테스트 코드를 먼저 작성한다.
- 이 테스트는 반드시 실패해야 한다. (아직 기능이 구현되지 않았으므로)
2. Green 단계: 테스트를 통과하는 코드 작성
- 테스트를 통과할 수 있는 최소한의 코드를 작성한다.
- 이 단계에서는 코드의 품질보다 테스트의 통과가 우선이다.
3. Refactor 단계: 코드 개선
- 중복을 제거하고 코드를 개선한다.
- 테스트가 여전히 통과하는지 지속적으로 확인한다.
TDD가 제공하는 두 가지 핵심 이점
마틴 파울러는 테스트 우선 작성(Test-First-Programming)이 제공하는 두 가지 이점을 강조한다.
1. 자체 코드 테스트 확보
모든 기능 코드는 반드시 테스트를 통과해야만 작성될 수 있기에 자연스럽게 높은 테스트 커버리지가 보장된다.
2. 인터페이스 중심의 설계
테스트를 먼저 작성함으로써 코드의 사용자 관점에서 먼저 생각하게 되며, 인터페이스와 구현의 분리를 자연스럽게 달성할 수 있다.
TDD의 추가적인 장점
1. 높은 코드 품질
- 테스트가 보장된 코드를 작성할 수 있다.
- 버그를 조기에 발견하고 수정할 수 있다.
2. 문서화
- 테스트 코드가 곧 명세가 되어 코드의 동작을 이해하는데 도움이 된다.
- 새로운 팀원이 코드를 이해하는데 유용하다.
3. 리팩토링 용이성
- 견고한 테스트를 바탕으로 안전하게 리팩토링할 수 있다.
- 코드 품질을 지속적으로 개선할 수 있다.
TDD 실패의 흔한 원인과 주의사항
1. 리팩토링 단계 소홀
마틴 파울러는 TDD를 실패하는 가장 흔한 원인으로 리팩토링 단계를 소홀히 하는 것을 꼽았다.
리팩토링 없이는 코드가 점차 지저분해지고, 테스트는 있지만 코드의 품질은 저하될 수 있다.
2. 실전 적용 시 주의사항
- 처음부터 완벽을 추구하지 말자
- 테스트의 품질도 중요하게 고려하자
- 모든 것을 TDD로 할 필요는 없다는 것을 이해하자
마무리
TDD는 단순해 보이는 프로세스 속에 깊이 있는 통찰과 원칙이 담겨 있는 방법론이다. 초기에는 개발 속도가 더딜 수 있으나, 장기적으로는 높은 품질의 소프트웨어를 만들고 유지보수하는데 큰 도움이 된다.
Reference
