•
이상적인 환경이라면, 클래스 변경 작업 시 딱히 해야할 일이 별로 없다.
•
테스트 하네스에서 클래스의 객체를 생성하면 곧바로 구현에 들어가면 된다. 그러나 대부분은 그렇지 않다.
•
테스트 루틴을 작성하려면 테스트 대상 클래스가 다른 클래스에 주는 영향을 알아야 할 때가 있다.
•
일반적으로 테스트 루틴을 작성할 때, 의존 관계를 제거하는 이유는 다음의 두 가지다.
1.
감지 : 코드 내에서 계산된 값에 접근할 수 없을 때, 이를 감지하기 위해 의존 관계를 제거한다.
2.
분리 : 코드를 테스트 하네스 내에 넣어서 실행할 수 없을 때, 코드를 분리하기 위해 의존 관계를 제거한다.
⇒ 감지는 테스트 과정에서 발생한 사이드 이펙트를 검증하려면 해당 의존성까지 체크해야되기 때문이라는 느낌이 들었고 분리는 의존성 생성이 어렵거나 강하게 결합되어있어 독립적으로 동작한다고 보기 어려울 때? 하는 거 같다.
협업 클래스 위장하기
•
레거시 코드를 다룰 때의 가장 큰 문제 중 하나가 의존 관계다.
•
특정 코드만 독립적으로 테스트하려면 대체로 다른 코드에 대한 의존 관계를 제거할 필요가 있다.
가짜 객체
•
특정 의존성을 대체하기 위해 먼저 인터페이스로 대체하고 이를 대신하는 가짜 객체를 사용해볼 수 있다.
가짜 객체의 양면성
•
가짜 객체는 의존성을 효과적으로 대체하면서 테스트에만 필요한 기능을 지원하곤 한다.
•
이때문에 우리는 기존 의존성을 가지는 객체를 완전히 대체할 수는 없음을 인지해야 한다.
모조 객체
•
가짜 객체를 많이 사용해야 한다면 발전된 형태인 모조 객체의 사용을 고려해 볼만 하다.
•
모조 객체는 내부적으로 검증을 수행하는 가짜 객체를 말한다.
import junit.framwork.*;
public class SaleTest extends TestCase {
public void testDisplayAnItem() {
MockDisplay display = new MockDisplay();
display.setExpectation("showLine", "Milk $3.99");
Sale sale = new Sale(display);
slae.scan("1");
display.verify();
}
}
Java
복사
•
모조 객체의 장점은 예상되는 메소드 호출을 모조 객체에 미리 알려주고 실제로 호출됐는지 검증하는 등의 작업이 가능하다는 점이다.
•
모조 객체는 매우 강력한 도구로 전용 프레임워크들이 즐비하다. 하지만 이는 모든 언어에서 사용 가능하진 않으며 대부분의 경우 간단한 가짜 객체만으로도 충분하다.
