TDD

리팩토링을 하다 보면 사이드 이펙트가 생기지 않을까 하는 두려움이 생겼기 때문두려움에 떨 시간, 빌드하면서 테스트 할 시간에 테스트 코드를 작성하여 이후 발생할 수 있는 리팩토링에도 유연하게 대처할 수 있는게 낫지 않을까? 하는 생각테스트 주도 개발은 프로그래밍하면서

$5 + 10CHF = $10$5 X 2 = $10amount를 private으로 만들기Dollar 부작용(side effect)?Money 반올림?equals() 🆕 hashCode() 🆕객체의 값(정확히는 amount) 를 비교해야 하기 때문에 equals 구현

8 ~ 11장의 궁극적인 목표: Dollar, Franc 중복 제거저번 시간에 이어 times() 의 중복을 없애면 Dollar, Franc 클래스는 아무 일도 하지 않게 된다.다만, 이 두 하위 클래스를 없애는 큰 단계를 한 번에 밟기보다는 우선 작은 단계부터 시작한

할일 목록$5 + 10 CHF = $10 (환율이 2:1인 경우)$5 + $5 = $10$5 + $5에서 Money 반환하기Bank.reduce(Money)Money에 대한 통화 변환을 수행하는 ReduceReduce(Bank, String)테스트코드부터 작성환율을 적

전체 애플리케이션을 대상으로 하는 것보다는 좀더 작은 스케일로 하는게 좋다각각의 테스트는 다른 테스트와 완전히 독립적이어야 한다. 즉, 실행 순서에 독립적이어야 한다.이렇게 테스트를 격리하기 위한 작업은 결과적으로 시스템이 응집도는 높고 결합도는 낮은 객체의 모음으로

이 질문은 사실 2가지 질문을 내포하고 있다.각 테스트가 다뤄야 할 범위는 얼마나 넓은가?리팩토링을 하면서 얼마나 많은 중간 단계를거쳐야 하는가?한 줄 정도의 작은 크기의 테스트를 만들 수 있는가 하면, 수백 줄의 로직과 수시간 분량의 리팩토링을 할 만큼의 크기를 갖는