바꾸기
할일 목록
$5 + 10 CHF = $10 (환율이 2:1인 경우)
$5 + $5 = $10
$5 + $5에서 Money 반환하기
Bank.reduce(Money)
Money에 대한 통화 변환을 수행하는 Reduce
Reduce(Bank, String)
저번에 완벽하게 구현하지 않은 reduce() 구현을 마무리할 차례다.
저번 시간에는 환율 개념을 도입하지 않았으므로 이번 시간에는 이를 구현한다.
즉, 은행(Bank)에 환율(rate)을 입력하고(addRate()), 돈을 넣어서 원하는 통화로 변환(reduce())한다.
이 문장을 그대로 위와 같이 테스트코드로 작성한다.
Bank
Money
이 때 문제는 2가 여전히 테스트코드와 클라이언트 코드 두 곳에서 반복된다는 것.
또한 이렇게 되면 기존 rate(환율) 수정이 어려울 뿐만 아니라 다른 통화 간의 환율을 추가하기 위해 분기문을 추가해야 한다는 단점도 존재합니다.
때문에 이러한 문제들을 해결하고자 Bank 에서 환율표를 가지고 있다가 필요할 때 찾아볼 수 있게 하기 위해 해시테이블 활용
Bank 에서 사용할 해시테이블, 즉 딕셔너리 생성. Key는 Pair
환율을 저장할 딕셔너리를 만들었으므로 환율을 설정할 수 있는 메서드도 만들어야 한다.
근데 앞에서 만들어준 테스트 케이스는 '다른 통화'에 대한 것이고, 통화가 같은 경우에 대해서는 고려하지 않았다.
따라서 통화가 같은 경우에 대한 테스트 코드를 추가해주고, 구현해준다.
이렇게 리팩토링을 하다가 문득 떠오르는 테스트 케이스가 있으면 테스트를 추가해주고 - 구현
할일 목록
$5 + 10 CHF = $10 (환율이 2:1인 경우)
$5 + $5 = $10
$5 + $5에서 Money 반환하기
Bank.reduce(Money)
Money에 대한 통화 변환을 수행하는 Reduce
Reduce(Bank, String)
환율에 대한 구현을 마침으로써 reduce 에 관한 모든 할일이 마무리 됐다.
서로 다른 통화 더하기
할일 목록
$5 + 10 CHF = $10 (환율이 2:1인 경우)
$5 + $5 = $10
$5 + $5에서 Money 반환하기
Bank.reduce(Money)
Money에 대한 통화 변환을 수행하는 Reduce
Reduce(Bank, String)
드디어 최종 과제인 다른 통화를 가진 화폐 더하기 작업을 할 차례이다.
앞 장에서 했던 작업은 통화 '하나'에 환율을 적용하여 축약(reduce)한 작업이고,
이번 장에서 할 일은 서로 다른 '두 통화'에 환율을 적용하여 축약(reduce)하는 것
테스트코드부터 작성하고 돌려보면 당연히 실패한다. result 는 15달러가 된다.
plus 의 구현을 따라가보면 Sum을 통함을 알 수 있다.
Money
Sum 에 대한 리팩토링을 진행할 차례다.
Sum
(리팩토링 전)
(리팩토링 후)
위와 같이 이전에 작업했던 reduce 를 통해 환율(rate) 를 적용한 amount 값을 얻으면 아래와 같이 테스트 코드를 정상적으로 통과시킬 수 있다.
Money 회고
다음에 할 일은 무엇인가
- 클래스가 인터페이스로 바뀌는 일이 잦은데, 그 반대는 일반적인 방향이 아니다.
- 난 "끝났다"라는 말을 믿지 않는다. 만약 시스템이 크다면, 당신이 늘 건드리는 부분들은 절대적으로 견고해야 한다. 그래야 안심하고 수정할 수 있다.
- 다음에 할 일이 무엇일까? 라는 질문은 어떤 테스트들이 추가로 더 필요할까? 로 볼 수 있다.
- 할 일 목록이 빌 때가 그때까지 설계한 것을 검토하기 적절한 시기다. 구조나 설계에 잘 못된점이나 개선점이 없는지 검토할 수 있다.
메타포
책을 작성하면서 1부 통화 예제를 서너 번 정도 짰는데 그 때마다 생각해낸 메타포에 따라 설계가 완전히 다른 방향으로 흘렀다.
돈가방, 지갑 등 여러 메타포를 생각해봤었고 책에 나온 예제에서는 Expression(수식) 메타포를 사용했다. 이에 따라 설계가 완전히 다른 방향으로 진행됐다.
코드 메트릭스
전체를 다 구현하게 아니라 절대적으로 평가할 순 없지만,
코드와 테스트 사이에는 대략 비슷한 양의 함수와 줄이 나타나게 된다.
프로세스
작은 테스트를 추가한다.
모든 테스트를 실행하고, 실패하는 것을 확인한다.
코드에 변화를 준다. (컴파일, 테스트 성공하도록)
모든 테스트를 실행하고, 성공하는 것을 확인한다.
중복을 제거하기 위해 리팩토링한다.
테스트의 질
TDD 과정동안 자연히 생기는 테스트들은 시스템의 수명이 다할 때까지 함께 유지돼야 할 만큼 확실히 유용하다.
하지만 이 테스트들이 다음과 같은 종류의 테스트들을 대체할 수 있을거라 예상해서는 안된다.
- 성능 테스트
- 스트레스 테스트
- 사용성 테스트
테스트에 대한 평가지표
- 명령문 커버리지
- 결함 삽입
전체 커버리지 수치에 대해
- 전체 커버리지 수치는 프로그램의 서로 다른 경우를 테스트하는 테스트 수 / 테스팅이 필요한 경우의 수(로직의 복잡도)
- 테스트 커버리지를 향상시키는 한 가지 방법은 더 많은 테스트를 작성하는 것이다.
- 이 책의 리뷰어인 플립은 반면, 테스트는 그대로 두고 '코드의 경우의 수(복잡도)를 줄여서' 즉, 로직을 단순화시켜서 커버리지를 높이기를 권장한다.
1부 최종 검토
- 테스트를 확실하게 돌아가게 만드는 세가지 접근법: 가짜로 구현하기, 삼각측량법(참, 거짓 모두 검증), 명백하게 구현하기
- 테스트 코드와 실제 코드 사이의 중복 제거하기
- 길이 미끄러우면 속도를 줄이고 상황이 좋으면 속도를 높이는 식으로 테스트 사이의 간격을 조절할 수 있는 능력
(할 일의 크기를 정할 때 지나치게 크게 잡는 것도 안 좋지만 지나치게 작게 잡는 것도 좋지 않음)
