est-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)을 발생 시키는 특수한 객체를 만들어 에러 상황에 대해 테스트할 수 있다.
깨진 테스트
- 개인 작업 프로그래밍 도중 깨진 테스트 케이스를 남겨둔 채로 세션(작업)을 끝내면 다시 일을 시작할 때 리마인드하는 시간을 줄일 수 있다.
깨끗한 체크인
- 팀 작업 프로그래밍의 경우 깨진 테스트 케이스가 없는 상태로 끝마치는 것이 좋다.
- 코드를 체크인(머지)하기 전 실행시킨 통합테스트에서 깨짐이 발생한다면 제대로 이해하지 못한 채로 프로그램을 작성했다는 뜻이므로 날리고...다시 작성하는 것이 좋다.
- 테스트를 통과하기 위해서 주석 처리를 하는 것은 엄격히 금지 한다.
Author And Source
이 문제에 관하여(est-Driven Development - Testing Pattern), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://velog.io/@versatile309/Test-Driven-Development-Testing-Pattern저자 귀속: 원작자 정보가 원작자 URL에 포함되어 있으며 저작권은 원작자 소유입니다.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)