스프링 부트에서 테스트 주도 개발 실습 - 2장. 타락한 객체

STS 4.0.1(스프링 부트)에서 

TDD(테스트 주도 개발 Test Driven Development) 실습하기

들어가는 글. 대다수의 사람들은 다음 두 가지 단순한 법칙을 따름으로써 잠재력을 한껏 발휘할 수 있다. 1. 어떤 코드건 작성하기 전에 실패하는 자동화된 테스트를 작성하라. 2. 중복을 제거하라.
요구사항 및 개선사항 목록        - $5 + 10CHF = $10 (환율이 2:1일 경우)        - $5 x 2 = $10  - amount를 private로 만들기  - Dollar 부작용(side effect)?   <- 이번 예제의 목표  - Money 반올림?	목적. 테스트 주도 개발의 리듬 이해 1. 재빨리 테스트를 하나 추가한다. 2. 모든 체스트를 실행하고 새로 추가한 것이 실패하는 지 확인한다 3. 코드를 조금 바꾼다. 4. 모든 테스트를 실행하고 전부 성공하는지 확인한다. 5. 리팩토링을 통해 중복을 제거한다.

2장. 타락한 객체 제목..이 :>   계속 읽다보면 켄트 벡 만의 위트를 알 수 있다. 

1. 진짜코드를 얻어가는 과정 이번 예제의 목표는 Dollar 부작용(side effect)?를 해결하는 과정으로 진행된다. 내용은 테스트를 연이어서 진행하면 캡쳐와 같이 에러가 터진다는 내용이다. 

1) 2차 테스트 추가 

에러를 보면 2차 테스트 결과를 15을 기대했지만 JUnit은 30이 나왔다고 한다. 코드 내용을 보면 1차 테스트를 통해 five 객체가 5가 아닌 10이 되버린 것으로 추정할 수 있을 것 같다. 

2) 개선의 과정 

(1) 1단계 : 실패하는 테스트 - 연산 결과를 five 객체가 아 별도의 product 객체에 담도록 수정

 
public class Chapter2 {
	@Test
	public void testMultiplication() {
		Dollar five = new Dollar(5);
		Dollar product; 
		
		//1차 조건, 테스트
		product = five.times(2);
		assertEquals(10, product.amount);
		
		//2차 조건, 테스트
		product = five.times(3);
		assertEquals(15, product.amount);		
	}
}

(2) 2단계 : 스텁 구현 - 일단 컴파일이 돌아가도록 수정

 
class Dollar{
	int amount;
	
	Dollar(int amount){
		this.amount = amount;
	}
	
	Dollar times(int multiplier) {
		amount *= multiplier;
                return null;
	}
}

(3) 3단계 : 진짜 구현 - 올바른 코드로 수정

 
public class Chapter2 {
	@Test
	public void testMultiplication() {
		Dollar five = new Dollar(5);
		Dollar product; 
		
		//1차 조건, 테스트
		product = five.times(2);
		assertEquals(10, product.amount);
		
		//2차 조건, 테스트
		product = five.times(3);
		assertEquals(15, product.amount);		
	}
}

class Dollar{
	int amount;
	
	Dollar(int amount){
		this.amount = amount;
	}
	
	Dollar times(int multiplier) {
		return new Dollar(amount * multiplier);
	}
}

3) 수정한 결과 

2. 교훈 

1) 최대한 빨리 녹색 바를 고는 방법 

(1) 가짜로 구현 하기 : 상수를 반환하게 만들고 진짜 코드를 얻을 때 까지 단계적으로 상수를 변수로 바꾸어 간다. 이른바  스텁 구현 (링크 페이지 맨 아래 각주 참고)

(2) 명백한 구현 사용하기 : 실제 구현을 입력한다.

2) 1~2장 요약

(1) 설계상의 결함(Dollar 부작용)을 그 결함으로 인해 실패하는 테스트로 전환 

(2) 스텁 구현으로 빠르게 컴파일 통과

(3) 올바르다고 생각하는 코드를 입력하여 테스트 통과