4장. 프라이버시

Dollar.times() 연산은 호출을 받은 객체의 값에 인자로 받은 곱수만큼 곱한 값을 갖는 Dollar를 반환해야한다. 하지만 테스트가 지금 정확히 그것을 말하지 않는다.

$5 + 10 CHF = $10(환율이 2:1일 경우)
$5 X 2 = $10
amount를 private으로 만들기
Dollar 부작용(side effect)?
Money 반올림
equals()
hashcode()
Equal null
Equal object

	@Test
    public void testMultiplication(){
        Dollar five = new Dollar(5);
        Dollar product = five.times(2);
        assertEquals(10, product.amount);
        product = five.times(3);
        assertEquals(15,product.amount);
    }

이전에 실행한 테스트는 Dollar와 Dollar의 비교연산이 가능해지면서 아래와 같이 수정이 가능해졌다.

	@Test
    public void testMultiplication(){
        Dollar five = new Dollar(5);
        Dollar product = five.times(2);
        assertEquals(new Dollar(10), product);
        product = five.times(3);
        assertEquals(new Dollar(15),product);
    }

추가적으로 아래의 product 변수는 쓸모가 없어 method 내부로 집어넣었다.

	@Test
    public void testMultiplication(){
        Dollar five = new Dollar(5);
        assertEquals(new Dollar(10), five.times(2));
        assertEquals(new Dollar(15),five.times(3));
    }

테스트를 고치고 나니 이제 Dollar의 amount 인스턴스 변수를 사용하는 코드는 Dollar 자신밖에 없게 됐다. 따라서 변수를 private으로 변경할 수 있다.

public class Dollar {
    private int amount;
.
.
.
}

$5 + 10 CHF = $10(환율이 2:1일 경우)
$5 X 2 = $10
amount를 private으로 만들기
Dollar 부작용(side effect)?
Money 반올림
equals()
hashcode()
Equal null
Equal object

이제 할일 목록의 또 다른 항목을 지울 수 있게 됐다.
하지만 위험한 상황을 만들었다는 점에 주목하라.

만약 동치성에 대한 코드가 정확히 작동한다는 것을 검증하는 데 실패한다면. 곱하기 테스트 역시 곱하기에 대한 코드가 정확하게 작동한다는 것을 검증하는데 실패하게 된다.

이것이 TDD를 하면서 적극적으로 관리해야 할 위험 요소이다.

우리는 완벽함을 위해 노력하지는 않는다. 모든 것을 두번 말함으로써(코드와 테스트로 한번씩) 자신감을 가지고 전진할 수 있을 만큼만 결함의 정도를 낮추기를 희망할 뿐이다.

우리의 추론이 맞지 않아서 결함이 손가락 사이로 빠져나가는 수가 있다. 그럴때면 테스트를 어떻게 작성해야 했는지에 대한 교훈을 얻고 다시 앞으로 나아간다.

다시 배운것을 검토해보자

• 오직 테스트를 향상시키기 위해서만 개발된 기능을 사용했다.
• 두 테스트가 동시에 실패하면 망한다는 점을 인식했다.
• 위험요소가 있음에도 불구하고 계속 진행했다.
  -테스트와 코드 사이의 결합도를 낮추기 위해, 테스트하는 객체의 새 기능을 사용했다.