📌 테스트 주도 개발, TDD(Test Driven Development)
![](/assets/img/cs/2022-07-23/test.webp)
요즘 한창 TDD 라는 단어를 종종 마주치는 것 같아서 한번 알아보려고 한다!
주제: 테스트 주도 개발, TDD(Test Driven Development)
테스트 주도 개발이 뭔가요?
프로그램에 대한 테스트를 미리 준비한 후에 실제 코딩을 진행하는 개발이다.
기존 개발 프로세스는 설계 후 코딩, 테스트의 과정을 밟지만,
TDD의 경우, 미리 테스트 케이스를 준비한 다음 코딩을 진행한다.
테스트를 미리 염두하고 진행하는 개발이므로 ‘테스트 주도(Driven) 개발’이다.
그리고 TDD의 테스트는 한 번의 거대한 테스트 일정이 아닌, 작은 단위의 반복적인 테스트를 의미한다.
짧고 반복?? 애자일 방법론이다. 그 중 eXtream Programming(XP) 유형의 구체적인 실천 방법 중 하나이다.
왜 테스트를 미리..? 왜 미리 하는거에요?
미리 테스트 케이스를 준비하면 정해진 목표 요구사항에만 집중할 수 있다.
정해진 목표 요구사항에만 집중할 수 있기 때문에 불필요한 설계를 피할 수 있다.
아 그냥 막 어? 어떻게 하면 되는게 개발이지 뭔 차이가 있는데요???
기존 일반적인 개발 프로세스와 애자일이 다른 점은 절차와 문서화보다 반복적인 피드백을 중요시한다는 점이다.
기존 개발 프로세스에서는 한 번의 많은 양의 요구사항을 절차에 따라 처리했다.
넓은 요구사항의 범위는 개발 방향을 의도치 않은 방향으로 이끌 수 있다.
그러나, XP는 작은 단위로 반복적인 개발을 진행하기 때문에 한 주기에 정해진 요구사항에 대해서만 처리한다.
그리고 즉각적 피드백을 통해 개발 방향을 교정한다.
그럼 이게 궁극적으로 무슨 효과가 있어요??
-
보다 튼튼한 객체 지향적인 코드 생산
TDD는 코드의 재사용 보장을 명시하므로 TDD를 통한 소프트웨어 개발 시 기능 별 철저한 모듈화가 이뤄진다. 이는 종속성과 의존성이 낮은 모듈로 조합된 소프트웨어 개발을 가능하게 하며 필요에 따라 모듈을 추가하거나 제거해도 소프트웨어 전체 구조에 영향을 미치지 않게 된다. -
재설계 시간의 단축
테스트 코드를 먼저 작성하기 때문에 개발자가 지금 무엇을 해야하는지 분명히 정의하고 개발을 시작하게 된다. 또한 테스트 시나리오를 작성하면서 다양한 예외사항에 대해 생각해볼 수 있다. 이는 개발 진행 중 소프트웨어의 전반적인 설계가 변경되는 일을 방지할 수 있다. -
디버깅 시간의 단축
이는 유닛 테스팅을 하는 이점이기도 하다. 예를 들면 사용자의 데이터가 잘못 나온다면 DB의 문제인지, 비즈니스 레이어의 문제인지 UI의 문제인지 실제 모든 레이러들을 전부 디버깅 해야하지만, TDD의 경우 자동화 된 유닛테스팅을 전재하므로 특정 버그를 손 쉽게 찾아낼 수 있다. -
테스트 문서의 대체 가능
주로 SI 프로젝트 진행 과정에서 어떤 요소들이 테스트 되었는지 테스트 정의서를 만든다. 이것은 단순 통합 테스트 문서에 지나지 않는다. 하지만 TDD를 하게 될 경우 테스팅을 자동화 시킴과 동시에 보다 정확한 테스트 근거를 산출할 수 있다. -
추가 구현의 용의함
개발이 완료된 소프트웨어에 어떤 기능을 추가할 때 가장 우려되는 점은 해당 기능이 기존 코드에 어떤 영향을 미칠지 알지 못한다는 것이다. 하지만 TDD의 경우 자동화된 유닛 테스팅을 전제하므로 테스트 기간을 획기적으로 단축시킬 수 있다.
어떤 상황에서 TDD를 하나요?
특히 불확실성이 높은 상황에 TDD는 좋은 선택지가 될 수 있다.
- 처음해보는 프로그램 주제
- 고객의 요구조건이 바뀔 수 있는 프로젝트
- 개발하는 중에 코드를 많이 바꿔야 된다고 생각하는 경우
- 내가 개발하고 나서 이 코드를 누가 유지보수할지 모르는 경우
구체적으로 어떻게 하나요?
![](/assets/img/cs/2022-07-23/tdd.webp)
TDD의 개발주기
- Red 단계에서는 실패하는 테스트 코드를 먼저 작성한다.
- Green 단계에서는 테스트 코드를 성공시키기 위한 실제 코드를 작성한다.
- Blue 단계에서는 중복 코드 제거, 일반화 등의 리팩토링을 수행한다.
위의 개발주기를 구체화 한 방법이다.
- 실패하는 작은 단위 테스트를 작성한다. 처음에는 컴파일조차 되지 않을 수 있다.
- 빨리 테스트를 통과하기 위해 프로덕션 코드를 작성한다. 이를 위해 정답이 아닌 가짜 구현 등을 작성할 수도 있다.
- 그 다음의 테스트 코드를 작성한다. 실패 테스트가 없을 경우에만 성공 테스트를 작성한다.
- 새로운 테스트를 통과하기 위해 프로덕션 코드를 추가 또는 수정한다.
- 1~4단계를 반복하여 실패/성공의 모든 테스트 케이스를 작성한다.
- 개발된 코드들에 대해 모든 중복을 제거하며 리팩토링한다.
TDD의 접근방법에는 여러 가지가 있다.
- 가짜로 구현하기: 최대한 빨리 테스트를 통과하기 위해 정답이 아닌 가짜 정답을 구현하는 방법
- 삼각측량법: 값이 다른 여러 테스트를 작성하고, 이를 일반화하여 정답을 구현하는 방법
- 명백하게 구현하기: 정답을 바로 구현하는 방법
단점도 있겠죠??
생산성 저하 문제가 있다.
반복적인 개발에 대해 피드백을 적용해야 하기 때문에 개발 속도가 일반적인 프로세스보다 느릴 수 밖에 없다.
출처
https://ko.wikipedia.org/wiki/익스트림_프로그래밍
https://mangkyu.tistory.com/182
http://clipsoft.co.kr/wp/blog/archives/6919
https://hanamon.kr/tdd란-테스트-주도-개발/