bbbomi / tdd-practice Goto Github PK

1부에서 해결해야 할 이슈 목록

이슈의 이름은 책에 나온 그대로를 따름.

• $5 + 10CHF = $10(환율이 2:1일 경우) #33
• $5 + $5 = $10 #31
• $5 + $5에서 Money 반환하기 #35
• Bank.reduce(Money) (Caused by #28) #29
• Money에 대한 통화 변환을 수행하는 Reduce (Caused by #29) #31
• Reduce(String, String) (Caused by #29) #31
• $5 * 2 = $10 #2
• amount를 private으로 만들기 (Caused by #2) #9
• Doller 부작용(side effect)? (Caused by #2) #5
• Money 반올림? (Caused by #2)
• equals() #7
• hashCode() (Caused by #7)
• Equal null (Cased by #7)
• Equal object (Caused by #7)
• 5CHF * 2 = 10CHF #11
• Dollar/Franc 중복 (Caused by #11) #18 #26
• 공용 equals (Caused by #11) #13
• 공용 times (Caused by #11) #24
• Franc과 Dollar 비교하기 (Caused by #13) #16
• 통화? (Caused by #16) #22
• testFrancMultiplication 제거 (Caused by #18) #26
• Sum.plus (Caused by #33) #35
• Expression.times (Caused by #33) #35

1. 해결하고자 하는 목표
   • Dollar와 같은 역할을 하는 또 다른 화폐단위인, Franc class 만들기

2. 해당 이슈에서 한 작업
   • 큰 테스트 공략 실패($5 + 10CHF = $10)
     그래서 진전을 나타낼 수 있는 자그마한 테스트를 만들었음.
   • 중복을 만들고 조금 고쳐서 테스트를 작성.
   • 모델 코드도 복사, 수정해서 테스트 통과.
   • 중복 개선이 필수적으로 필요하다고 느꼈음.

TDD의 궁극적인 목표 - 작동하는 깔끔한 코드(clean code that works, Ron Jeffries)

작동하는 깔끔한 코드가 훌륭한 이유는?

• 예측 가능한 개발 방법이다.
  끊임없이 발생할 버그에 대해 걱정하지 않고, 일이 언제 마무리 될 지 알 수 있다.
• 코드가 가르쳐 주는 모든 교훈을 학습할 기회를 갖게 된다.
  처음 생각나는 대로 후딱 완료해 버리면 두 번째 것, 더 나은 것에 대해 생각할 기회를 잃게 된다.
• 당신이 만든 소프트웨어는 사용자의 삶을 향상시켜 준다.
• 동료들이 당신을 존경할 수 있게 해주며, 당신 또한 동료들을 존경할 수 있게 해준다.
• 작성하는 동안 기분이 좋다!

TDD에서의 규칙

• 오직 자동화된 테스트가 실패할 경우에만 새로운 코드를 작성한다.
• 중복을 제거한다.

이 규칙이 촉직하는 행동 패턴

• 매 (설계에 대한)결정사항에 대해 피드백을 제공하는 실행 가능한 코드를 기반으로 하는 유기적인 설계를 해야 한다.
• 자동화 된 테스트를 다른 사람이 만들어주길 기다릴 수는 없으므로, 직접 테스트를 작성해야 한다.
• 개발 환경은 작은 변화에도 빠르게 반응할 수 있어야 한다.
• 테스트를 쉽게 만들려면 반드시 응집도는 높고 결합도는 낮은 컴포넌트들로 구성되게끔 설계해야 한다.

이 규칙에 의해 결정되는 프로그래밍 순서

1. 실패하는 작은 테스트를 작성한다.
   • 처음에는 컴파일조차 되지 않을 수 있다.
2. 빨리 테스트가 통과하게끔 만든다.
   • 이를 위해 아래의 것들을 해도 좋다.
     • 기존 코드 복붙하기
     • 테스트만 간신히 통과할 수 있게끔 함수가 무조건 특정 상수를 반환하도록 구현하기
3. 일단 테스트를 통과하게만 하는 와중에 생겨난 모든 중복을 제거한다(리팩토링)

---

1. 해결하고자 하는 목표
   • 통화 단위가 같은 화폐의 합을 구하기

2. 해당 이슈에서 한 작업
   • 모든 중복이 제거되기 전까지는 테스트를 통과한 것으로 간주하지 않았음!
   • 구현하기 위해 그 전과 다르게 역방향이 아닌 순방향으로 작업.
   • 앞으로 필요할 것으로 예상되는 객체(Sum)의 생성을 강요하기 위한 테스트를 작성

1. 해결하고자 하는 목표
   • 통화 개념 도입

2. 해당 이슈에서 한 작업
   • 큰 설계 아이디어를 다루려다 더 작은 작업을 수행.
   • 다른 부분들을 호출자(팩토리 메서드)로 옮김으로써 두 생성자를 일치 시킴.
   • 비슷한 리팩토링(Franc에 했던 일을 Dollar에도 적용)을 한 번의 큰 단계로 처리.
   • 동일한 생성자들을 상위 클래스로 올렸음.

1. 해결하고자 하는 목표
   • 설계 상의 결함을 테스트를 통해 해결한다.

2. 해당 이슈에서 한 작업
   • 설계 상의 결함(Dollar 부작용)을 그 결함으로 인해 실패하는 테스트로 변환.
   • Stub 구현으로 빠르게 컴파일을 통과하도록 만들었음.
   • 올바르다고 생각하는 코드를 입력하여 테스트를 통과.

1. 해결하고자 하는 목표
   • Dollar의 필드인 amount를 private으로 만들기

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

1. 해결하고자 하는 목표
   • 서로 다른 통화 더하기

2. 해당 이슈에서 한 작업
   • 원하는 시나리오 작성
   • 추상적인 선언을 통해 가지에서 뿌리(테스트 케이스)로 일반화 했음
   • 변경 후, 그 영향을 받은 다른 부분들을 연쇄적으로 변경

1. 해결하고자 하는 목표
   • Dollar와 Franc의 중복 제거

2. 해당 이슈에서 한 작업
   • 하위 클래스의 속을 들어내는 걸 완료, 하위 클래스를 삭제
   • 기존의 소스 구조에서는 필요했지만 새로운 구조에서는 필요 없게 된 테스트를 제거

Factory Method Pattern?

객체를 만들어내는 부분을 서브 클래스에 위임하는 패턴.

즉, new 키워드를 호출하는 부분을 서브 클래스에 위임하는 것.
결국 팩토리 메소드 패턴은 객체를 만들어내는 공장(Factory 객체)을 만드는 패턴이라 이해하면 됨.

implementation

의도

• 객체 생성을 캡슐화
  • 객체를 생성하기 위해 인터페이스를 정의하지만, 어떤 클래스의 인스턴스를 생성할지에 대한 결정은 서브클래스가 내리게 함.

구현 시 고려할 점들

• 팩토리 메서드 패턴의 구현 방법은 크게 두 가지
  • Creator를 추상 클래스로 정의, 팩토리 메서드는 abstract로 선언하는 방법.
  • Creator가 구체 클래스이고, 팩토리 메서드의 기본 구현을 제공하는 방법.
• 팩토리 메서드의 인자를 통해 다양한 Product를 생성하게 함.
  • 팩토리 메서드에 잘못된 인자가 들어올 경우의 런타임 에러 처리에 대해 고민해야 함.
  • Enum 등을 사용하는 것도 고려할 필요가 있음.
• 프로그래밍 언어 별로 구현 방법에 차이가 있을 수 있음.

1. 해결하고자 하는 목표
   • Money의 통화 단위 변환

2. 해당 이슈에서 한 작업
   • 필요할 거라고 생각한 파라미터를 빠르게 추가함
   • 코드와 테스트 사이에 있는 데이터 중복을 끄집어냄
   • 별도의 테스트 없이 전용(private) 도우미(helper) 클래스를 만들었음
   • 문제를 분리하기 위해 또 하나의 테스트를 작성하면서 진행했음.

1. 해결하고자 하는 목표
   • 공용 times 중복 제거

2. 해당 이슈에서 한 작업
   • 두 times()를 일치시키기 위해, 그 메서드들이 호출하는 다른 메서드들을 인라인 시킨 후 상수를 변수로 변경.
   • 디버깅을 위해 테스트 없이 toString()을 작성.
   • Franc 대신 Money를 반환하도록 변경을 시도, 그것이 잘 작동 할 지를 테스틀함.
   • 실험해본 걸 뒤로 물리고 또 다른 테스트를 작성.
     • 테스트를 작동했더니 원래 실험하던 것도 잘 작동하는 것을 확인.

1. 해결하고자 하는 목표
   • Dollar 클래스와 Franc 클래스 사이의 중복 코드 제거하기

2. 해당 이슈에서 한 작업
   • 공통된 코드를 Dollar에서 상위 클래스(Money)로 옮김.
   • Franc도 Money의 하위 클래스로 만들었음
   • 불필요한 구현을 제거하기 전에 두 equals() 구현을 일치시켰음.

1. 해결하고자 하는 목표
   • Dollar와 Franc 중복 줄이기

2. 해당 이슈에서 한 작업
   • 동일한 메서드(times)의 두 변이형 메서드 시그니처를 통일시킴으로써 중복 제거를 향해 한 단계 더 전진했음!
   • 최소한 메서드 선언부만이라도 공통 상위 클래스(superclass)로 옮김.
   • factory method를 도입하여 테스트 코드에서 콘크리트 하위 클래스의 존재 사실을 분리.
   • 하위 클래스가 사라지면 몇몇 테스트는 불필요한 여분의 것이 된다는 것을 확인(변경 x)

1. 해결하고자 하는 목표
   • Dollar와 Franc 비교하기

2. 해당 이슈에서 한 작업
   • 결함을 테스트에 담아냈음.
   • 완벽하진 않지만 (getClass())으로 테스트를 통과하게 만들었음.
   • 더 많은 동기가 있기 전에는 더 많은 설계를 도입하지 않기로 했음.
     • equals()에서 java 객체의 용어(getClass())를 사용하는 것 보다 재정 분야에 맞는 용어를 사용하는 것이 더 나아보임.
     • 하지만, 현재는 통화(currency) 개념 같은 게 없고, 도입할 충분한 이유가 없어 보이므로 TO-DO 리스트에만 달아놓기로 결정.

1. 해결하고자 하는 목표
   • Dollar와 Dollar를 직접 비교할 수 있다.

2. 해당 이슈에서 한 작업
   • 우리의 디자인 패턴(value object pattern)이 하나의 또 다른 operation을 암시 한다는 것을 알았음.
   • 해당 operation을 테스트.
   • 해당 operation을 간단히 구현했음.
   • 곧장 리팩토링 하는 대신 테스트를 조금 더 추가.
   • 두 경우를 모두 수용할 수 있도록 리팩토링.

1. 해결하고자 하는 목표
   • TO-DO 리스트에서 꼭 구현해야 하는 최소한의 작업 수행과 추상화

2. 해당 이슈에서 한 작업
   • 다른 사람들을 염두에 둔 테스트를 작성
   • 한 번의 선언부에 대한 수정이 시스템 나머지 부분으로 번져갔고, 문제를 고치기 위해 컴파일러의 조언을 따랐음
   • 잠시 실험을 시도했다가 좋지 못해서 버렸음.

1. 해결하고자 하는 목표
   • 어떤 금액(주가)을 어떤 수(주식의 수)에 곱한 금액을 결과로 얻을 수 있어야 한다.

2. 해당 이슈에서 한 작업
   • 우리가 알고 있는 작업해야 할 TO-DO 목록을 만들었음.
   • Operation이 외부에서 어떻게 보이길 원하는지 말해주는 이야기를 코드로 표현.
   • JUnit에 대한 상세한 사항들은 잠시 무시.
   • Stub 구현을 통해 테스트를 통과.
   • 좋지 못한 방법으로 테스트를 통과.
   • 돌아가는 코드에서 상수를 변수로 변경 -> 점진적으로 일반화
   • 새로운 할 일들을 한 번에 처리하는 대신 TO-DO 목록에 추가하고 넘어감.

1. 해결하고자 하는 목표
   • Bank에서의 reduce(Money)가 가능하게 하기

2. 해당 이슈에서 한 작업
   • 일단 한 곳에 캐스팅을 이용해서 코드를 구현했다가, 테스트 통과 확인 후 그 코드를 수정.
   • 명시적인 클래스 검사를 제거하기 위해 다형성을 사용.