테스트 주도 개발 [10 - 17장]

다음에 할 일은 무엇인가?

자주 건드리는 부분이 견고 하다면 가장자리, 즉 자주 바뀌지 않는 부분으로 흘러감에 따라 테스트는 더 듬성듬성 불규칙적이게 되고 디자인도 않 좋아지지만 안심할 수 있다.

어떤 테스트들이 추가로 필요할까?

때로는 실패해야 하는 테스트가 성공하는 경우가 있는데, 그럴 땐 그 이유를 찾아내야 한다. 또는 실패해야 하는 테스트가 실제로 실패하기도 하는데, 이때는 이를 이미 알려진 제한사항 또는 앞으로 해야 할 작업 등의 의미로 그 사실을 기록해둘 수도 있다. (히스토리를 쌓는다.)

할 일 목록

할 일 목록이 비었다면 그때까지 설계한 것을 검토하기에 적절한 시기다. 

 

메타포(은유)

• 설계 구조에 미치는 메타포의 엄청난 영향

public interface Expression {

    Money reduce(Bank bank, String to);

    Expression plus(Expression addend);

    Expression times(int multiplier);

}

 

Expression (메타포)는 중복되는 통화를 합치는 세세한 문제를 해결해주었다. 덕분에 코드는 그 어느 때보다도 더 명확해졌다. 

* 켄트백은 Money 예제를 여러번 작성했는데 그때마다 다른 메타포를 사용해왔다. MoneySum -> MoneyBag -> Wallet -> Expression 테스트를 작성할 수록 좋은 방향으로 나아갔다.

 

프로세스

1. 작은 테스트를 추가한다.
2. 모든 테스트를 실행하고, 실패하는 것을 확인한다.
3. 코드에 변화를 준다.
4. 모든 테스트를 실행하고, 성공하는 것을 확인한다.
5. 중복을 제거하기 위해 리팩토링한다.

 

최종 검토

• 테스트를 확실히 돌아가게 만드는 세가지 접근법: 가짜로 구현하기, 삼각측량법, 명백하게 구현하기
• 설계를 주도하기 위한 방법으로 테스트 코드와 실제 코드 사이의 중복을 제거하기
• 속도를 줄이고 높이는 식으로 테스트 사이의 간격을 조절할 수 있는 능력

 

1부 정리

• 요구사항 해결 방법(Money -> Sum -> Expression)
• 요구사항 -> 할 일 목록 테스트 -> 객체, 메소드 테스트  + 검증
• 실패한 테스트 해결 방법

Money 예제는 내가 아무리 TDD로 전개 하더라도 객체지향에 대한 이해와 경험, 직관이 없다면 어려울것 같다. 때문에 TDD 방법과 TDD를 해내가는 과정에 집중하자.