[테스트 주도 개발] 27장_테스팅 패턴

이 패턴들은 더 상세한 테스트 작성법에 대한 것이다.

자식 테스트

지나치게 큰 테스트 케이스를 어떻게 돌아갈 수 있을까 ? 원래 테스트 케이스의 깨지는 부분에 해당하는 작은 테스트 케이스를 작성하고 그 작은 테스트케이스가 실행되도록 해라. 그 후에 다시 원래의 큰 테스트 케이스를 추가해라.

Mock Object

비용이 많이 들거나 복잡한 리소스에 의존하는 객체를 테스트하려면 어떻게 해야할까 ? 상수를 반환하게끔 만든 속임수 버젼의 리소스를 만들면 된다.
예를 들어, 데이터베이스는 시작 시간이 오래 걸린고 깨끗한 상태를 유지하기 어렵다. 그리고 만약 데이터베이스가 원격 서버에 있다면 테스트 성공 여부가 네트워크 상의 물리적인 영향을 받게 된다. 또, 데이터베이스는 개발 중 많은 오류의 원인이다. 해법은, 진짜 데이터베이스를 사용하지 않는 것이다.
모의 객체를 사용하면 성능과 견고함 이외에, 가독성이 좋아진다. 또한, 가시성에 대해 고민하도록 격려해서 설계에서 커플링이 감소하도록 한다.
하지만 모의 객체를 사용하면, 프로젝트에 위험 요소가 추가된다. 모의 객체가 진짜 객체와 동일하게 동작하지 않으면 어떻게 될까 ? 모의 객체용 테스트 집합을 진짜 객체가 사용 가능해질때 그대로 적용해서 이 위험을 줄일 수 있다.

Crash Test Dummy

호출되지 않을 것 같은 에러코드를 어떻게 테스트할 것인가 ? 실제 작업을 수행하는 대신 그냥 예외를 발생시키기만 하는 특수한 객체를 만들어서 호출한다.
파일 시스템에 여유 공간이 없을 경우 발생할 문제에 대해 테스트를 해보자. 자바의 익명 내부 클래스는 테스트하기 원하는 메서드만이 오류를 발생하게끔 하기 위해 유용하다.

@Test
void testFileSystemError(){
    File file = new File("foo") {
        public boolean createNeweFile() throws IOException {
            throw new IOException();
        }
    };
    
    try {
        saveAs(file);
        fail();
    } catch (IOException e){
        
    }
}

깨진 테스트

혼자서 프로그래밍할 때 프로그래밍 세션을 어떤 상태로 끝내는게 좋을까 ? 마지막 테스트가 깨진 상태로 끝내라.
나중에 다시 코딩할 때, 어느 작업부터 시작할 것인지 명백히 알 수 있다. 전에 하고 있던 생각에 대한 명확하고 구체적인 책갈피를 가지는 것이다.

깨끗한 체크인

팀 프로그래밍을 할 때 프로그래밍 세션을 어떤 상태로 끝내는게 좋을까 ? 모든 테스트가 성공항 상태로 끝내라.
팀 프로젝트에서 프로그래밍 세션을 시작하는 경우면, 자신이 마지막으로 코딩한 다음부터 지금까지 무슨 일이 일이 있었는지 세밀하게 알 수 없다. 안심이 되고 확신이 있는 상태에서 시작할 필요가 있다.

---

테스트 주도 개발 <켄트 벡>