[테스트 코드] TDD란?
TDD(Test Driven Development)란?
TDD란 Test Driven Development의 약자로 ‘테스트 주도 개발’ 이고, 소프트웨어를 개발하는 여러 방법론 중 하나 입니다. 제품이 정상적으로 동작하는지 확인하기 위해서 모든 코드는 테스트를 거치게 됩니다. TDD에서는 해당 기능이 정상적으로 움직이는지 검증하기 위한 테스트 코드를 작성합니다. 이를 통해 테스트가 실패할 경우, 테스트를 통과하기 위한 최소한으로 코드를 개선합니다. 최종적으로 테스트에 성공한 코드를 리팩토링 하는 과정을 거칩니다.
TDD 프로세스
- Red - 실패하는 테스트 코드를 먼저 작성합니다.
- Green - 테스트 코드를 성공시키기 위한 실제 코드를 작성합니다.
- Blue - 중복 코드 제거, 일반화 등의 리팩토링을 수행합니다.
중요한 것은 실패하는 테스트 코드를 작성할 때까지 실제 코드를 작성하지 않는 것과, 실패하는 테스트를 통과할 정도의 최소 실제코드를 작성해야하는 것입니다. 이를 통해 실제 코드에 기대되는 바를 보다 명확하게 정의 함으로써 불필요한 설계를 피할 수 있고, 정확한 요구 사항에 집중할 수 있습니다.
일반 개발 방식 vs TDD 개발 방식
일반적인 개발
일반적인 개발 방식은 ‘요구사항 분석 → 설계 → 개발 → 테스트 → 배포’ 형태로 개발 주기를 갖게 됩니다.
이 방식은 소프트웨어 개발을 느리게 하는 잠재적 위험이 존재합니다.
- 요구사항이 처음부터 정확하지 않습니다.
- 완벽한 설계가 불가능 합니다.
- 자체 버그 검출 능력 저하 또는 소스코드의 품질이 저하될 수 있습니다.
- 자체 테스트 비용이 증가할 수 있습니다.
개발을 진행하다보면 클라이언트들의 요구사항은 계속해서 변경되고 설계를 꼼꼼하게 하더라도 완벽하게 설계할 수 없기 때문입니다.
요구사항 또는 디자인의 오류 등 많은 외부 또는 내부 원인에 의해, 점차 완벽한 설계로 나아갑니다. 재설계가 되는 과정에서 코드가 변경되면 불필요한 코드가 생길 수 있습니다.
작은 부분의 기능 수정에도 모든 부분을 테스트해야 하므로 전체적인 버그를 검출하기 어려워집니다. 따라서 버그를 검출하는 능력이 저하 됩니다.
TDD 개발
TDD와 일반적인 개발 방식의 큰 차이점은 테스트 코드를 작성한 뒤에 실제 코드를 작성한다는 점입니다. 설계 단계에서 프로그래밍 목적을 반드시 정의해야 하고, 테스트 케이스를 미리 작성 해야 합니다.
- 테스트 코드를 작성하는 도중 발생하는 예외 사항(버그 및 수정사항)은 테스트 케이스에 추가하고 설계를 개선합니다.
- 테스트가 통과된 코드만을 코드 개발 단계에서 실제 코드로 작성합니다.
이러한 반복적인 단계가 진행되면 자연스럽게 코드의 버그가 줄어들고 코드도 간결해집니다.
TDD 개발의 장점
보다 튼튼한 객체 지향 코드 구현
TDD는 코드의 재사용 보장을 명시하므로 TDD를 통한 소프트웨어 개발 시 기능 별 철저한 모듈화가 이뤄집니다.
이는 종속성과 의존성이 낮은 모듈로 조합된 소프트웨어 개발을 가능하게 하며 필요에 따라 모듈을 추가하거나 제거해도 소프트웨어 전체 구조에 영향을 미치치 않게 됩니다.
재설계 시간의 단축
테스트 코드를 먼저 작성하기 때문에 개발자가 지금 무엇을 해야하는지 분명히 정의하고 개발을 시작하게 됩니다.
또한 테스트 시나리오를 작성하면서 다양한 예외사항에 대해 생각해 볼 수 있습니다.
이는 개발 진행 중 소프트웨어의 전반적인 설계가 변경되는 일을 방지할 수 있습니다.
디버깅 시간의 단축
사용자의 데이터가 잘못 나온다면 데이터 문제인지, 서비스 문제인지, UI 문제인지 모든 부분에서 디버깅을 해야합니다.
TDD의 경우 자동화 된 유닛 테스팅을 전제하므로 특정 버그를 손 쉰게 찾아낼 수 있습니다.
테스트 문서의 대체 가능
주로 SI 프로젝트 진행 과정에서 어떤 요소들이 테스트 되었는지 테스트 정의서를 만듭니다.
이것은 단순 통합 테스트문서에 지나지 않습니다.
하지만 TDD를 하게 될 경우 테스팅을 자동화 시킴과 동시에 보다 정확한 테스트 근거를 산출 할 수 있습니다.
추가 구현의 용의함
개발이 완료된 소프트웨어에 어떤 기능을 추가할 때 가장 우려되는 점은 해당 기능이 기존 코드에 어떤 영향을 미칠지 알지 못한다는 것입니다.
TDD의 경우 자동화된 유닛 테스팅을 전제하므로 테스트 기간을 획기적으로 단축시킬 수 있다.
TDD 개발의 단점
생산성 저하
2개의 코드를 짜야하고 중간중간 테스트를 하면서 고쳐나가야 하기 때문에 시간이 오래 걸린다는 단점이 있습니다.
TDD 방식의 개발 시간은 일반적인 개발 방식에 비해 대략 10~30% 정도로 늘어납니다.
SI 프로젝트에서는 소프트웨어의 품질보다는 납기일 준수가 훨씬 중요하기 때문에 TDD 방식을 잘 사용하지 않습니다.
마무리
지금까지 일반적인 개발 방식으로 개발을 진행해 왔습니다.
가장 큰 단점은 요구사항 대로 개발을 다 진행하고 테스트를 진행하기 때문에 클라이언트들의 요구사항이 변경되면 다시 수정해서 개발을 진행해야 했습니다.
그리고 테스트를 한번에 진행하다 보니 디버깅 수도 많아지고 시간도 오래걸리는 문제가 항상 있었습니다.
TDD 개발 방식을 적용해 디버깅 시간을 단축하고 다양한 예외사항을 생각함으로써 주도적으로 코드를 작성해 보려고 합니다.