: 실제 객체를 만들어 사용하기에는 시간, 비용 등의 cost가 높거나, 혹은 객체 서로간의 의존성이 강해 구현하기 힘들 경우 가짜 객체를 만들어 사용하는 방법
테스트, 그 중에서도 단위 테스트를 할 때에는 보통 한 번에 하나의 메소드만을 실행해본다.
단, 이때 이 메소드가 다른 DB나 네트워크 등의 제어하기 어려운 것들에 의존하고 있다면 문제가 될 수 있다. 즉, 해당 Flow가 아닌 다른 것들에 의존하고 있다면 단위테스트를 하기 어려운 환경이기 때문이다.
이런 경우에 Mock Object의 개념을 활용하여 테스트를 한다.
테스트 작성을 위한 환경 구축이 어려운 경우
테스트가 특정 경우나 순간에 의존적인 경우
테스트 시간이 오래 걸리는 경우
개인 PC의 성능이나 서버의 성능 문제로 오래 걸릴 수 있는 경우, 시간을 단축하기 위해 사용한다.
: 테스트를 진행하기 어려운 경우, 이를 대신하여 테스트를 진행할 수 있도록 만들어주는 객체
Mock 객체와 유사한 의미를 가짐
조금 더 상위 의미로 사용됨
단순히 인스턴스화 될 수 있는 수준으로만 객체를 구현한 것
인스턴스화 객체가 필요할 뿐, 해당 객체의 기능까지는 필요하지 않은 경우 사용
: 더미 객체보다 조금 더 구현된 객체로, 더미 객체가 마치 실제로 동작하는 것처럼 보이게 만들어놓은 객체이다.
객체의 특정 상태를 가정해서 만들어, 특정 값을 리턴해주거나 특정 메시지를 출력해주는 작업을 함
특정 상태를 가정해서 하드코딩 된 형태 ➡ 로직에 따른 값의 변경은 테스트할 수 없음
즉, stub : 어떤 행위가 호출되었을 때, 특정 값으로 리턴시켜주는 형태
: 여러 상태를 대표할 수 있도록 구현된 객체
➡ 실제 로직이 구현된 것처럼 보이게 한다.
실제로 DB에 접속해서 비교할 때와 동일한 모양이 보이도록, 객체 내부에 구현할 수 있다.
테스트케이스 작성을 위해, 다른 객체들과의 의존성을 제거하기 위해 사용
페이크 객체를 만들 때에 복잡도로 인해 노력이 많이 들어갈 경우, 적절한 수준에서 구현하거나, Mock 프레임 워크를 사용함
페이크 객체를 생성하기 위한 노력이 많이 필요할 경우, 실제 객체를 가져와 테스트
테스트 더블로 구현된 객체에 자기 자신이 호출되었을 때, 확인이 필요한 부분을 기록하도록 구현한다.
특정 테스트 메소드가 몇 번 호출되었는지 필요한 경우, 전역 변수로 카운트를 설정하고 특정 메소드 카운트를 올리는 부분을 추가한 후, 이 카운트를 가져오는 메소드를 추가한다.
'특정 메소드가 호출되었을 때, 또 다른 메소드가 실행되어야 한다' 등의 행위 기반 테스트가 필요한 경우 사용한다.
: 행위를 검증하기 위해 사용되는 객체
수동으로 만들 수도 있고, 프레임워크를 통해 만들 수도 있다.
행위 기반 테스트는 복잡도나 정확성 등 작성하기 어려운 부분이 많기 때문에, 상태 기반 테스트가 가능하다면 만들지 않는다.
Mock 객체
➡ 총 2가지 의미로 사용될 수 있다.
💡 요약
- Mock Object : 행위 검증(Behavior verification)에 사용
- Stub은 상태 검증(State Verification)에 사용
Mock 프레임워크가 꼭 필요한지 확인한다.
어떤 Moxk 프레임워크를 사용하느냐는 핵심 문제가 아니다.
Mock 객체는 Mock일 뿐이다.
실제 객체로 작동을 해 보았을 때, 잘 작동하지 않을 수도 있다.
참고자료