[book] : TDD 실천법과 도구 - 은행계좌를 통한 TDD 예

퀜트백(XP 창시자)은 TDD를 프로그램을 작성하기 전에 테스트를 먼저 작성하는것이라 했다
즉 코드를 검증하는 테스트 코드를 먼저 만든 다음에 실제 작성해야하는 프로그램 코드작성에 들어가라는 뜻이다

TDD 개발의 진행 방식은 아래와 같다

    1. 질문(ASK) 테스트 작성을 통해 시스템에 질문한다.(테스트 수행결과는 실패 : Fail(RED))
    2. 응답(Respond) 테스트를 통과하는 코드를 작성해서 질문에 대답한다 (테스트 성공 : Pass())  
    3. 정재(Refine) 아이디어는 통합하고 불필요한 것은 제거하고 모호한것은 명확히 해서 대답을 정재한다 (Refactoring)
    4. 반복(Repeat) 다음 질문을 통해 다화를 계속 진행한다.

TDD Cycle

실제 간단한 예시 은행계좌 프로세스로 생각해본다
간단한 은행계좌 클래스를 만들어야 한다고 판단이 되었다고 했을때 TDD 흐름은 아래와 같다

은행계좌 예제를 통한 TDD FLow 

1. 구현해야할 기능을 파악하고 목록을 작성한다
   목록은 아래와 같다고 가정한다.
   - 계좌 잔고 조회
   - 입금
   - 출고

2. 계좌 잔고 테스트 코드를 작성한다.
2.1 계좌 잔고 조회 질문 코드를 작성한다 처음 질문은  Fail 질문 이다 
(단 Account 클래스의 대한 테스트 TDD는 완료 되었다고 가정하자 너무 설명이 길어진다.)

@Test
  public void testGetBalance() {
      Account acount = new Account(10000);
      assertEquals("10000원으로 계좌 생성 후 잔고 조회",10000,account.getBalance());
      
      // 계속적 테스트 케이스 보강 및 추가 반복
  }
 

테스트 코드를 실행해 본다.
위코드는 실제 구현부 getBalance 가 없기 때문에 Fail을 얻는다.

2.2. 테스트 코드의 따른 Pass(Green)을 얻기위해 계좌 잔고 조회 응답 Case를 작성한다.
   getBalance 메소드를 만들어준다.

public class Account{
      private int balance;
      public Account(int i){
          this.balance = i
      }
      public int getBalance(){
           return this.balance;  
      }
  }

테스트 코드를 실행해 본다.
그린을 얻는것을 확인한다.

2.3. 리팩토링을 한다.
   리팩토링에서 고민의 시간을 갖는다.
   - 소스의 가독성이 적절한가
   - 중복된 코드는 없는가
   - 이름이 잘못 부여된 메소드나 변수명은 없는가
   - 구조의 개선이 필요한 부분은 없는가

위 코드중에는 Account의 생성자 파라미터 i가 의미 없는 변수이기에 의미있는 money로 refactoring 한다.

public class Account{
      private int balance;
      public Account(int money){
          this.balance = money
      }
  }

2.4 테스트 케이스 추가 및 보완할 부분을  반복한다.
       이단계에서 잔고 조회에 대한 추가 테스트 케이스 및 테스트 케이스 보강 할부분이 있으면 테스트 케이스를 더 추가하고
       위과정을 2.1 ~ 2.3 을 반복한다.
        테스트 케이스는 한번에 여러개 하는거 보다 한건한건 추가하고 위과정을 반복하는거를 추천한다.

3. 입금 테스트 코드를 작성한다.
3.1 입금처리 질문 테스트 코드를 작성한다.

@Test
  public void testDeposit() {
      Account acount = new Account(10000);
      acount.deposit(1000)
      assertEquals("10000원으로 계좌 생성 후 1000원 입고후 잔고 조회",11000,account.getBalance());
      
      // 계속적 테스트 케이스 보강 및 추가 반복
  }

테스트 코드를 실행해 본다.
위코드는 실제 구현부 desposit이 없기 때문에 Fail을 얻는다.

3.2. 테스트 코드의 따른 Pass(Green)을 얻기위해 입금 응답 case를 작성한다.
  Account Class에 아래  메소드 추가

  public void deposit(int money){
      return this.balance+=money;  
  }

3.2 .리팩토링한다.   
3.3 이단계에서 입금 테스트 케이스 보강할부분이 있으면 테스트 케이스를 더 추가하고 위과정을 반복할수있다.

4. 출고기능도 위의 위이 과정을 반복한다.

위과정은 테스트 케이스를 하나씩 추가해나가면서 구현 클래스를 점진적으로 만드는 과정을 설명한것이다
처음 TDD를 접하는 분들은 위의 구현 클래스의 점진적 만드는 과정을 추천한다.

다른 방법으로는 클래스의 외형에 해당하는 메소드들을 먼저 만들고 나서 테스트 케이스를 일괄적으로 만드는 방법이 있다
무엇이 옳고 그름은 없지만 대부분의 TDD책에서는 점진적 방법을 추천한다.


참고 : PIVOTAL DDD 온라인 세미나
https://www.youtube.com/watch?v=QUMERCN3rZs