[소프트웨어 테스트] 08. 테스트 주도 개발

소프트웨어 테스트 시리즈의 글입니다.

TDD에 대해 이야기해보자

8.1 TDD

TDD는 ‘개발을 유도하는 테스트’ 과정의 일부다.

8.2 TDD 고찰

반복 개발 프로세스

구현하고자하는 기능에 대한 단위테스트를 작성. (→아직 기능이 구현되지 않아 테스트 실패)
기능을 구현. (→ 테스트 통과)
리팩토링 = red-green refactor cycle

장점

요구사항을 먼저 살펴보기때문에 불필요한 코드를 작성하지 않게됨
제품코드 작성 속도를 제어 가능.
피드백이 빠름.
테스트 가능한 코드를 작성하게됨.
설계에 대한 피드백을 바로 얻게됨. (테스트 = 첫번째 클라이언트)

8.3 현업에서의 TDD

은탄환은 없다.. (=완벽한 정답은 당연히 X) TDD가 유익할지 알아보는 좋은 방법은 직접 시도해보는것

8.3.1 TDD인가, 아닌가?

TDD를 하지 않아도 동일한 이점을 누릴 수 있지만, 필자는 TDD의 리듬을 선호함 개발주기를 명확하게 정의하고, 코드를 자주 검토할수 있게됨 테스트가 통과할때 자연스럽게 검토를 수행하게되기때문 클래스 설계는 가장 어려운 작업중 하나인데, TDD 를 사용하면 보다 최선설계가 가능해짐. (설계+실행 모두 고려) 코드를 먼저 작성하고 테스트를 작성하면 피드백을 얻기 위한 시간 단축이 과제가 되어버림..

8.3.2. 항상 TDD ?

실용적으로는 당연히 ‘아니오’ 필자도 TDD를 적극 사용하지만 모든시간을 투자하지는 않음

설계나 아키텍처, 특정 요구사항에 대한 구현방법이 명확하지 않을때 TDD사용
복잡한 문제나 해당 문제에 전문성이 부족할때 TDD사용
개발과정에서 배울만한게 없고 이미 다 알고있는 내용이면 TDD 사용X
일부 복잡한기능(어떤 테스트를 먼저 작성할지 결정하기 어려운경우) TDD 사용X

8.3.4 TDD와 관련한 연구

긍정적 효과를 보여주는 연구 + 그렇지 않은 연구 모두 있음. 둘다 완벽한 연구는 아님. 최근의 논문에서는 TDD와같은 프로세스가 집중력, 흐름을 개선하고 안정된 단계를 가지도록 하기 때문에 이점을 가지는거라는 분석도..

8.3.5 다양한 TDD 학파

고전주의 TDD 학파 (=detroit inside-out TDD) : 내부 → 외부로 테스트 작성. 즉 엔티티부터 작성. 모의객체 사용을 지양함. 전체를 한번에 테스트하는것에 집중
모의 객체 중심주의 TDD 학파(London outside-in TDD) : 외부 → 내부로 테스트 작성. 여러 객체가 연동하는 방식에 초점을 맞추고 모의객체를 많이 사용. 단위를 격리해서 테스트.
필자는 두 학파를 혼합해서 사용한다고함. (내부 → 외부로 짜지만, 단위테스트를 많이 사용)

8.3.6 TDD와 정식 테스트

TDD로 만든 테스트 스위트가 이전 장에서 다룬 테스트 관행으로 설계한 강력하고 체계적인 테스트 스위트만큼 훌륭하다고 생각하지는 않음. TDD는 ‘개발을 유도하는 테스트’ 영역임. 테스트가 개발 프로세스를 유도하게하려면TDD를 사용하고, 이후에 코드가 안정됐다면 기존의 테스트 관행을 따라 체계적인 테스트를 시작할 때. TDD + 효율적 테스트 조합은 두 가지 모두 제때 수행해야 의미가있음.