[27장] 테스팅 패턴
<자식 테스트>
작은 테스트 케이스를 작성하고 그 작은 테스트 케이스가 실행되도록 하라. 그 후에 다시 원래의 큰 테스트 케이스를 추가하라.
빨강/초록/리팩토링 리듬은 성공이 지속되는데 중요하다.
나는 큰 테스트를 작성하고 나면 우선 교훈을 찾기 위해 노력한다. 왜 테스트가 그렇게 컸을까? 어떤 다른 방식을 취했더라면 좀더 작게 만들 수 있었을까?
<모의 객체(Mock Object)> : 가짜 객체(Fake It)와는 다르다. 스스로 검증할 수 있는 능력이 있고, 외부에서 결과값을 조정할 수 있다.
비용이 많이 들거나 복잡한 리소스에 의존하는 객체를 테스트하려면 어떻게 해야 할까? 상수를 반환하게끔 만든 속임수 버전의 리소스를 만들면 된다.
마치 데이터베이스인 것처럼 행동하지만 실제로는 메모리에만 존재하는 객체를 통해 작성될 수 있다.
성능과 견고함 이외에 모의 객체의 또 다른 가치는 가독성에 있다.
모의 객체는 당신이 모든 객체의 가시성에 대해 고민하도록 격려해서, 설계에서 커플링이 감소하도록 한다. 모의 객체를 사용하면 프로젝트에 위험 요소가 하나 추가된다. 모의 객체가 진짜 객체와 동일하게 동작하지 않으면 어떻게 될까?
<셀프 션트(shunt)> : 자기가 보낸 것이 다시 자신에게 제대로 돌아오는 지 확인하는 루프백 테스트와 유사하다.
셀프 션트 패턴은 테스트 케이스가 구현할 인터페이스를 얻기 위해 인터페이스 추출을 해야 한다. 인터페이스를 추출하는 것이 더 쉬운지, 존재하는 클래스를 블랙 박스로 테스트하는 것이 더 쉬운지는 당신이 결정해야 할 것이다. 인터페이스에 대한 구현은 또한 적절한 값을 되돌리거나 부적절한 오퍼레이션이 호출된 경우 예외를 던지게끔 만들어야 할 것이다.
<로그 문자열>
메시지의 호출 순서가 올바른지를 검사하려면 어떻게 해야할까?
로그 문자열은 특히 옵저버를 구현하고, 이벤트 통보가 원하는 순서대로 발생하는지를 확인하고자 할 때 유용하다.
<크래시 테스트 더미>
호출되지 않을 것 같은 에러 코드(발생하기 힘든 에러 상황)를 어떻게 테스트할 것인가? 실제 작업을 수행하는 대신 그냥 예외를 발생시키기만 하는 특수한 객체를 만들어서 이를 호출한다.
객체 전체를 흉내낼 필요가 없다는 점을 제외하면 크래시 테스트 더미는 모의 객체와 유사하다. 우리가 테스트하기 원하는 적절한 메서드만이 오류를 발생시키게끔 하기 위해 유용하게 쓰인다.
<깨진 테스트>
혼자서 프로그래밍할 때 프로그래밍 세션을 어떤 상태로 끝마치는 게 좋을까? 마지막 테스트가 깨진 상태로 끝마치는 것이 좋다.
나중에 다시 코딩하기 위해 돌아왔을 때, 어느 작업부터 시작할 것인지 명백히 알 수 있다. 전에 하고 있던 생각에 대한 명확하고 구체적인 책갈피를 가지게 되는 것이다.
<깨끗한 체크인>
팀 프로그래밍을 할 때 프로그래밍 세션을 어떤 상태로 끝마치는 게 좋을까? 모든 테스트가 성공한 상태로 끝마치는 것이 좋다.
따라서 코드를 체크인하기 전에 항상 모든 테스트가 돌아가는 상태로 만들어 두어야 한다. 통합 테스트 슈트에서 테스트가 실패하는 경우도 있을 것이다. 그럴 땐 어떻게 해야 할까?
가장 단순한 규칙은 그동안 작업한 코드를 날려버리고 다시 하는 것이다. 실패한 테스트는 방금 여러분이 만들어 낸 프로그램을 여러분이 완전히 이해하지 못했음을 말해주는 강력한 증거다. 만약 전체 팀원이 이 규칙을 따른다면 체크인을 더 자주하려는 경향이 생길 것이다. 왜냐하면 제일 먼저 체크인하는 사람은 작업을 날릴 위험이 없을 테니까.
댓글