<테스트 주도 개발(TDD)의 리듬>
1.재빨리 테스트를 하나 추가한다.
2.모든 테스트를 실행하고 새로 추가한 것이 실패하는지 확인한다.
3.코드를 조금 바꾼다.
4.모든 테스트를 실행하고 전부 성공하는지 확인한다.
5.리팩토링을 통해 중복을 제거한다.
⇒
-각각의 테스트가 기능의 작은 증가분을 어떻게 커버하는지
-새 테스트를 돌아가게 하기 위해 얼마나 작고 못생긴 변화가 가능한지
-얼마나 자주 테스트를 실행하는지
-얼마나 수 없이 작은 단계를 통해 리팩토링이 되어가는지
[1장] 다중 통화를 지원하는 Money 객체
어떤 테스트들이 있어야(이 테스트들이 모두 통과할 경우) 코드가 완성됐다는 걸 확신할 수 있을까?
앞으로 어떤 일을 해야 하는지 알려주고, 지금 하는 일에 집중할 수 있도록 도와주며, 언제 일이 다 끝나는지 알려줄 수 있게끔 할일 목록을 작성해보자.
객체를 만들면서 시작하는 게 아니라 테스트를 먼저 만들어야 한다.
복잡한 테스트가 보인다면, 작은 것부터 시작하든지 아니면 아예 손을 대지 않는 게 좋다.
테스트를 작성할 때는 오퍼레이션의 완벽한 인터페이스에 대해 상상해보는 것이 좋다.
작은 단계로 시작 한다. 이런 문제들을 적어 놓고 계속 진행하자. 지금 우리에겐 실패하는 테스트가 주어진 상태고 최대한 빨리 초록 막대를 보고 싶을 뿐이다.
최초에 작성한 테스트는 컴파일조차 되지 않는다. 실행은 안 되더라도 컴파일만은 되게 만들고 싶다.
한 번에 하나씩 정복한다. 그냥 컴파일만 되게 할 거니까 생성자 안에서는 아무 일도 안 해도 된다.
스텁 구현 : 컴파일 될 수 있도록 껍데기만 만들어두는 것을 뜻한다
컴파일만 될 수 있게 해주는 최소한의 구현만 할 것 이다.
리팩토링 : 코드의 외적 행위는 그대로 유지하면서 내부 구조를 변경하는 작업을 뜻한다.
<의존성과 중복>
테스트와 코드 간의 문제는 중복이 아님을 지적한 바 있다. - 스티브 프리만
문제는 테스트와 코드 사이에 존재하는 의존성이다. 즉 코드나 테스트 중 한쪽을 수정하면 반드시 다른 한쪽도 수정해야만 한다는 것이다.
의존성이 문제 그 자체라면 중복은 문제의 징후다. 가장 흔한 예는 로직의 중복이다.
다음 테스트로 진행하기 전에 중복을 제거함으로써, 오직 한가지(one and only one)의 코드 수정을 통해 다음 테스트도 통과하게 만들 가능성을 최대화하는 것이다.
Once and only once, 즉 필요한 것을 하되(once) 단 한 번만(only once)하라는 뜻의 익스트림 프로그래밍 실천사항과 통한다.
이 단계가 너무 작게 느껴지는가? 하지만 기억하기 바란다. TDD의 핵심은 이런 작은 단계를 밟아야 한다는 것이 아니라, 이런 작은 단계를 밟을 능력을 갖추어야 한다는 것이다.
[정리]
-우리가 알고 있는 작업해야 할 테스트 목록을 만들었다.
-오퍼레이션이 외부에서 어떻게 보이길 원하는지 말해주는 이야기를 코드로 표현했다.
-스텁 구현을 통해 테스트를 컴파일했다.
-끔찍한 죄악을 범하여 테스트를 통과시켰다.
-상수를 변수로 변경하여 점진적으로 일반화했다.
-새로운 할일들을 한번에 처리하는 대신 할일 목록에 추가하고 넘어갔다.
[2장] 타락한 객체
<TDD 주기>
1.테스트를 작성한다. : 이야기를 써내려가는 것이다. 올바른 답을 얻기 위해 필요한 이야기의 모든 요소를 포함시켜라.
2.실행 가능하게 만든다. : 깔끔하고 단순한 해법이 명백히 보인다면 그것을 입력하라.
3.올바르게 만든다. : 좁고 올곧은 소프트웨어 정의(software righteousness)으 길로 되돌아와서 중복을 제거하고 초록 막대로 되돌리자.
우리 목적은 작동하는 깔끔한 코드를 얻는 것이다.
도달하기 힘든 목표다. 그렇다면 나누어서 정복하자(divide and conquer). 일단 ‘작동하는 깔끔한 코드’를 얻어야한다는 전체 문제 중에서 ‘작동하는’에 해당하는 부분을 먼저 해결하라. 그러고 나서 ‘깔끔한 코드’ 부분을 해결하는 것이다.
아키텍처 주도 개발과 정반대다.
어떤 구현이 올바른가에 대한 우리 추측이 완벽하지 못한 것과 마찬가지로 올바른 인터페이스에 대한 추측 역시 절대 완벽하지 못하다.
최대한 빨리 초록색을 보기 위해 취할 수 있는 내가 아는 세 전략 중 두가지다.
1.가짜로 구현하기
2.명백한 구현 사용하기
3.삼각측량(triangulation)
에상치 못한 빨간 막대를 만나게 되면 뒤로 한발 물러서서 가짜로 구현하기 방법을 사용하면서 올바른 코드로 리팩토링한다.
[정리]
-설계상의 결함을 그 결함으로 인해 실패하는 테스트로 변환했다.
-스텁 구현으로 빠르게 컴파일을 통과하도록 만들었다.
-올바르다고 생각하는 코드를 입력하여 테스트를 통과했다.
느낌(부작용에 대한 혐오감)을 테스트로 변화하는 것은 TDD의 일반적 주제다.
댓글