테스트 주도 개발은 테스트 우선 개발과 유사하지만 작은 차이가 있는데 이 차이는 프로그래머에게 여러 기회를 제공한다고 한다. 오늘은 이 강의를 통해 테스트 주도 개발을 통해 명세를 준수하고 일정 수준의 품질을 유지하며 코드로 만들어 가는 과정을 경험할 예정이다.
테스트 주도 개발 절차
테스트 주도 개발은 3가지 단계가 반복적으로 사이클이 돌아간다.
- RED - 실패하는 테스트 추가한다.
- GREEN - 테스트를 통과하기 위한 구현한다.
- REFACTOR - 통과한 테스트의 구현 설계를 개선, 기존 테스트가 통과해야한다
테스트 실패 (RED)
- 구체적인 하나의 요구사항을 검증하는 하나의 테스트를 추가한다.
- 추가된 테스트가 실패하는지 확인한다.
-> 실패하는 것을 확인해야 테스트가 동작함을 믿을 수 있다.
-> 운영 코드 변경이 진행되지 않았기 때문에 실패했는지 확인해야 한다.
테스트 성공 (GREEN)
- 추가된 테스트를 비롯해 모든 테스트가 성공하도록 운영 코드를 변경한다.
- 테스트 성공은 요구사항을 만족한다는 의미이다.
-> 코딩의 가장 중요한 임무이다. - 테스트 성공을 위한 최소한의 변경만 있어야 한다.
-> 가장 중요한 임무를 가장 빠르게 완수한다.
-> 요구사항을 만족하기 위한 최소한의 뼈대만 세우면 된다, 살 붙이는건 중요도가 낮다
개선 (REFACTOR)
- 코드베이스 정리한다.
- 구현 설계 개선한다.
-> 가독성, 적응성, 성능에 대해서 개선한다.
-> 인터페이스가 아닌 구현 설계 개선을 의미한다. - 모든 테스트 성공을 전제한다.
켄트벡의 설계 규칙
- 통과하는 테스트 (Passes the tests) - 설계의 가장 중요한 목적이다.
- 의도 노출 (Reveals intention) - 가독성을 높인다는 것과 유사할 수 있다.
- 중복 제거 (No duplication) - 앞으로 있을 수도 있는 코드 변경에 대응하기 쉽다.
- 가장 작은 요소 (Fewest elements) - 위의 3가지 규칙에 불필요한 요소는 제거한다.
주의점 - 의도 노출과 중복 제거는 서로 충돌할 수 있어서 같은 우선순위에 둔다고 한다
테스트 주도 개발 세부 흐름
테스트 주도 개발은 낯설지 않다
흔히 이슈 발생을 생각해보면 TDD와 비슷하다는 걸 깨달을 수 있다.
버그 발생(제보) -> 버그 재현 -> 코드 수정 -> 버그 재현 -> 작업완료
테스트 주도 개발 비용
위의 그래프를 보면 TDD 를 적용하는게 모두 좋은건 아니다. t1 시점이 오기전까지 추가적인 기능 없이 운영이 된다면 TDD 미사용이 더 비용이 낮고 시간도 아낀다.t1 시점이 와도 TDD 가 좋은건 아니다. 이전 격차만큼 t2 까지는 TDD 미사용이 더 비용이 저렴하다.
지속적인 기능 확장이 되면 TDD 미사용이 엄청나게 개발 속도가 느려지게 된다. 원인은 이전 기능에 대한 테스트가 전혀 없기 때문에 기능을 모두 재검증 해야 한다. 그에 반해 TDD는 테스트 자동화로 손쉽게 피드백을 받아 확인할 수 있다. 개발자라면 지속적인 기능 확장이 있는지 파악하고 TDD를 적용할지 판단해야한다.
하지만 TDD를 더 잘할 수 있게 되거나, TDD와 관련된 도구가 발달하여 TDD를 사용할 때 드는 비용 자체를 줄 일 수 있다면, 즉 t1, t2 시점이 더 앞으로 땡겨진다면 TDD 도입을 적극적으로 생각해보면 된다.
회고
뭔가 오늘은 드디어 테스트 주도 개발에 대한 핵심에 돌입한 느낌이 들었다. 그리고 아직은 테스트 우선 개발과 테스트 주도 개발의 차이를 잘 모르겠다.
