[32장] TDD 마스터하기
단계가 얼마나 커야 하나?
-각 테스트가 다뤄야 할 범위는 얼마나 넓은가?
-리팩토링을 하면서 얼마나 많은 중간 단계를 거쳐야 하는가?
시간이 지남에 따라 테스트 주도 개발자의 경향은 분명히 나타난다. 단계가 점점 작아지는 것이다. 자동화된 리팩토링 툴은 리팩토링을 엄청나게 가속화시킨다. 훌륭한 툴의 지원이 있다는 걸 알고 있다면 코드가 어떤 구조를 갖추길 원하는지 보기 위해 여러 가지 실험을 시도하면서 리팩토링에 훨씬 적극적이게 될 것이다.
테스트할 필요가 없는 것은 무엇인가?
“두려움이 지루함으로 변할 때까지 테스트를 만들어라.”
다음 것들을 테스트해야 한다.
-조건문
-반복문
-연산자
-다형성
당신이 작성하는 것들에 대해서만 테스트해라. 불신할 이유가 없다면 다른 살마이 만든 코드를 테스트하지 마라.
좋은 테스트를 갖췄는지의 여부를 어떻게 알 수 있는가?
다음은 설계 문제가 있음을 알려주는 테스트의 속성이다.
-긴 셋업 코드
-셋업 중복
-실행 시간이 오래 걸리는 테스트 : 작은 부분만 테스트할 수 없다는 것은 설계 문제를 의미하고 설계를 적절히 변경해줄 필요가 있다.
-깨지기 쉬운 테스트
TDD로 프레임워크를 만들려면 어떻게 해야 하나?
-첫 번째 기능을 구현한다. 이 첫번째 기능은 단순하고 직관적으로 구현되고, 따라서 짧은 시간 안에 결함도 적은 상태로 완성된다.
-첫 번째 기능에 대한 변주가 되는 두 번째 기능을 구현한다. 두 기능사이의 중복이 한 곳으로 모이고, 서로 다른 부분은 다른곳(다른 메서드나 심지어는 다른 클래스)으로 옮겨진다.
-앞의 두 기능에 대한 변주로 세 번째 기능을 구현한다. 공통의 로직은 약간의 수정만으 ㄹ통해 재활용 가능한 상태로 만들어질 수 있을 것이다. 그리고 곹오적이지 않은 로직들은 다른 메서드 혹은 클래스 등 명확하게 로직이 있어야 할 곳에 있게 되는 경향이 있다.
개방-폐쇄 원칙 : 객체는 사용에 대해서는 열려 있어야 하고 향후 수정에 대해서는 닫혀 있어야 한다.
피드백이 얼마나 필요한가?
나는 테스트를 얼마나 작성할지 고려할 때, 실패간 평균시간(MTBF, Mean Time Between Failures)을 생각한다. 어떤 테스트를 작성할 필요가 있을지 없을지는 당신이 MTBF를 얼마나 조심스럽게 측정하는지에 달렸다. TDD의 테스트에 대한 관점은 실용적이다. TDD에서 테스트는 어떤 목적을 위한 하나의 수단이다. 만약 어떤 구현에 대한 지식이 신뢰할 만 하다면 그에 대한 테스트느는 작성하지 않을 것이다.
테스트를 지워야 할 때는 언제인가?
-첫째 기준은 자신감이다. 테스트를 삭제할 경우 자신감이 줄어들 것 같으면 절대 테스트를 지우지 말아야 한다.
-둘째 기준은 커뮤니케이션이다. 두 개의 테스트가 코드의 동일한 부분을 실행하더라도, 이 둘이 서로 다른 시나리오를 말한다면 그대로 남겨두어야 한다.
별 부가적인 이득이 없는 중복된 테스트가 두 개 있다면, 덜 유용한 것을 삭제하라.
거대한 시스템을 개발할 때에도 TDD를 할 수 있는가?
시스템에 있는 기능의 양은 TDD의 효율에 영향을 미치지 않는 것 같다. 중복을 제거함에 따라 더 작은 객체들이 만들어지게 되고, 이 작은 객체들은 애플리케이션의 크기와 무관하게 독립적으로 테스트될 수 있다.
애플리케이션 수준의 테스트(ATDD, Application Test-Driven Development)로도 개발을 주도할 수 있는가?
기술적문제 : 고정물을 만드는 것. 아직 만들지 않은 기능에 대한 테스트를 어떻게 작성하고 실행할 것인가?
사회적인 문제 : 기존에 없던 구현하기 전이라는 기존에 존재하지 않던 단계에서 책임이 수반된다.
테스트와 피드백 사이의 길이도 문제가 될 수 있다.
프로젝트 중반에 TDD를 도입하려면 어떻게 해야 할까?
테스트를 염두에 두지 않고 만든 코드는 테스트하기가 그리 쉽지 않다는 점이다. 일부부만을 격리해서 실행하고 결과를 검사할 수 있게끔 인터페이스가 설계되어 있지 않다.
“고치면 되잖아”하고 말할 수도 잇을 것이다. 맞다. 하지만 리팩토링 과정에 에러를 만들 수도 있는데, 아직 테스트가 없기 때문에 에러가 생겼다는 점을 알아낼 수 없을 것이다. 닭과 달걀 문제.
확실히 하지 말아야 할 일이 있는데, 그것은 코드 전체를 위한 테스트를 한꺼번에 다 만들고, 코드 전체를 한번에 리팩토링하는 일이다.
따라서 우선 해야 할 일은 변경의 범위를 제한하는 것이다.
다음으로 해야 할 일은 테스트와 리팩토링 사이에 존재하는 교착상태를 풀어주는 것이다.
TDD는 누구를 위한 것인가?
TDD는 더 깔끔한 설계를 할 수 있도록, 그리고 더 많은 것을 배워감에 따라 설계를 더 개선할 수 있도록, 적절한 때 적절한 문제에 집중할 수 있게끔 도와준다.
TDD는 오버액션이다. TDD는 현재 업게에서 통용하는 수준보다 훨씬 더 적은 수의 결함과 훨씬 더 깨끗한 설계의 코드를 작성하게 해준다. 그렇지만 우아함에서 영혼의 안식을 찾는 이들은 선을 실행하면서 잘 사는 방법을 TDD에서 찾을 수 있다.
TDD는 시간이 지남에 따라 코드에 대한 자신감을 점점 더 쌓아갈 수 있게 해준다. 테스트가 쌓여감에 따라 시스템의 행위에 대한 자신감을 더 많이 얻게 된다. 설계를 개선해 나감에 따라 점점 더 많은 설계 변경이 가능해진다.
어째서 TDD가 잘 작동하는가?
결함을 빨리 발견해 고칠수록 비용은 낮아진다.
설계 결정에 대한 피드백 고리를 단축시킨다.
이름을 테스트 주도 개발이라고 한 이유는?
개발:개발이란 분석,논리적 설계, 물리적 설계, 구현, 테스팅, 검토, 통합, 배포를 아우르는 복잡한 춤을 말한다.
테스트:자동화되고 구체적이며 명확한 테스트를 말한다. TDD는 분석 기술이며, 설계 기술이기도 하다. 사실은 개발의 모든 활동을 구조화하는 기술이다.
TDD와 익스트림 프로그래밍의 실천법 사이에 어떤 관련이 있는가?
짝프로그래밍
활기차게 일하기
지속적입 통합
단순 설계
리팩토링
지속적인 전달
댓글