Test-Driven Development - Testing Pattern

자식 테스트

• 큰 테스트 케이스가 깨질 경우: 깨진 부분에 대해 작은 테스트 케이스를 작성하고 통과시킨 후 원래의 테스트 케이스를 복구
• 큰 테스트 코드의 처리법:
  1. 삭제하고 단계별 작은 테스트 케이스를 추가
  2. 실행되지 않도록 해놓고 작은 테스트 케이스를 추가

  삭제하지 않을 경우 작은 테스트 케이스를 작성하고 통과 시키는 동안 작동하지 않는 테스트가 두 개가 된다는 점을 유념.

모의 객체(Mock Object)

• 모의 객체의 이점: 성능, 견고함, 가독성
• 모의 객체는 개발자가 가시성에 대해 고민하도록 해 설계에서 커플링이 감소하도록 한다.
• 모의 객체가 진짜 객체와 동일하게 동작하지 않을 수 있다는 점이 위험 요소다.

셀프 션트(self shunt)

• 테스트 케이스 자체를 모의 객체로 사용하는 패턴
• 테스트 하고 싶은 객체의 클래스를 인터페이스화 해서 테스트 케이스가 해당 인터페이스를 구현하도록 한다

//0개 언어 사용자라 그냥 수도코드로 작성.
interface Printer {
  void print()
}

class Program {
  void callPrint(Printer printer) {
    printer.print();
  }
}
//테스트가 인터페이스를 구현
class PrinterTest implements Printer {
  int callCount = 0;
//인터페이스에 선언되어 있던 테스트
  void print() {
    this.callCount += 1;
  }
  
  void callPrintTest() {
    Program program = Program();
    program.callPrint(this);
    expect(this.callCount).toBe(1); //잘 불렀는지 확인
  }
}

흥미로운 방법이긴 한데 mocking 해야하는 객체가 많을 경우 어려움이 있을 것 같다. 모의 객체를 사용하는 것과 비교해서 어떤 이점이 있는걸까? 일단 class들을 인터페이스화 한다는 점에서 클래스간 결합도를 낮출 수 있을 것 같긴 하다.

로그 문자열

• 이벤트 발생 시마다 로그를 추가하는 것으로 이벤트 발생 순서를 테스트할 수 있다.

크래시 테스트 더미

• 예외(Exception)을 발생 시키는 특수한 객체를 만들어 에러 상황에 대해 테스트할 수 있다.

깨진 테스트

• 개인 작업 프로그래밍 도중 깨진 테스트 케이스를 남겨둔 채로 세션(작업)을 끝내면 다시 일을 시작할 때 리마인드하는 시간을 줄일 수 있다.

깨끗한 체크인

• 팀 작업 프로그래밍의 경우 깨진 테스트 케이스가 없는 상태로 끝마치는 것이 좋다.
• 코드를 체크인(머지)하기 전 실행시킨 통합테스트에서 깨짐이 발생한다면 제대로 이해하지 못한 채로 프로그램을 작성했다는 뜻이므로 날리고...다시 작성하는 것이 좋다.
• 테스트를 통과하기 위해서 주석 처리를 하는 것은 엄격히 금지 한다.