정의
TDD란 Test Driven Development의 약자로 '테스트 주도 개발'이라고하며, 소프트웨어를 개발하는 여러 방법론 중 하나이다.
짧은 개발 주기의 반복에 의존하는 개발 프로세스이며,
애자일 방법론 중 하나인 eXtream Programming(XP)의 'Test-First' 개념에 기반을 둔 단순한 설계를 중요시한다.
간단하게 말하면 테스트를 먼저 만들고 테스트를 통과하기 위한 것을 짜는 것이다
즉, 만드는 과정에서 우선 테스트를 작성하고 그걸 통과하는 코드를 만들고를 반복하면서 제대로 동작하는지에 대한 피드백을 적극적으로 받는 것이다.
TDD에서는 제품의 기능 구현을 위한 코드와 별개로, 해당 기능이 정상적으로 움직이는지 검증하기 위한 테스트 코드를 작성한다.
TDD 개발 프로세스
3가지 단계로 나눌 수 있다.
- RED: 실패하는 테스트 코드 작성
- GREEN: 테스트 코드를 성공시키기 위한 실제 코드 작성
- REFACTOR: 코드 베이스 정리, 구현 설계 개선
중요한 것은 실패하는 테스트 코드를 작성할 때까지 실제 코드를 작성하지 않는 것과, 실패하는 테스트를 통과할 정도의 최소 실제 코드를 작성해야 하는 것이다.
이를 통해, 실제 코드에 대해 기대되는 바를 보다 명확하게 정의함으로써 불필요한 설계를 피할 수 있고, 정확한 요구 사항에 집중할 수 있다
효과
1.단위 테스트로 인해 동작하는 코드에 대해 자신감을 가질 수 있다.
TDD를 사용하면, 코드가 내 손을 떠나 사용자에게 도달하기 전에 문제가 없는지 먼저 진단 받을 수 있다. 그러므로 코드가 지닌 불안정성과 불확실성을 지속적으로 해소해준다.
2. 디버깅하는 시간이 현저히 줄어들 뿐만 아니라, 잘못된 코드에 대해 빠른 오류 확인이 가능하다
당장은 단위 테스트 작성에 추가적인 노력이 든다고 생각할 수 있지만, 전체 개발 주기를 생각했을 때 이러한 노력이 담긴 테스트를 통해서 결국 생산성이 향상된다.
3. 테스트 코드 작성 단계에서 실제 코드에 대한 명확한 처리를 설계함으로써 과도한 설계를 피할 수 있고, 간결한 인터페이스를 갖는다
단점
1. 생산성의 저하
개발 속도가 느려진다고 생각하는 사람이 많기 때문에 TDD에 대해 반신반의 한다.
왜냐하면 처음부터 2개의 코드를 짜야하고, 중간중간 테스트를 하면서 고쳐나가야 하기 때문이다.
TDD 방식의 개발 시간은 일반적인 개발 방식에 비해 대략 10~30% 정도로 늘어난다.
SI 프로젝트에서는 소프트웨어의 품질보다 납기일 준수가 훨씬 중요하기 때문에 TDD 방식을 잘 사용하지 않는다.
2. 개발방식 변화의 어려움
이제까지 자신이 개발하던 방식을 많이 바꿔야 하기 때문에 몸에 체득한 것이 많을수록 바꾸기가 어렵다.
TDD는 오히려 개발을 별로 안해본 사람에겐 적용하기가 쉽다.
3. TDD에 대한 선입견/고정관념
TDD는 이렇게 해야된다는 이미지/틀이 있다. ‘반드시 툴(단위 테스트 프레임워크)을 써서 이렇게 해야된다.’라고 생각한다.
하지만 이런 규칙에 얽매이는 것은 애자일이 아니다. 결국엔 규칙에 얽매여 똑같은 테스트를 copy&paste 하게될 수 있다.
참고
https://inpa.tistory.com/entry/QA-📚-TDD-방법론-테스트-주도-개발
https://media.fastcampus.co.kr/knowledge/dev/tdd/
댓글