Mocks Aren't Stubs - Martin Fowler 02 Jan 2007

https://martinfowler.com/articles/mocksArentStubs.html

Mocks Aren't Stubs

 

 

요약 비교표

구분	Mockist Style (Mock을 활용하는 TDD)	Classical Style (전통적인 TDD)
검증 대상	행동 검증	상태 검증
검증 방식	객체 간의 상호작용을 검증함.	객체의 최종 상태를 검증함.
초점	시스템 간의 행동이 어떻게 연결되는지 디자인에 집중 행동의 연결을 검증	연산 결과에 집중하며,  연산 후 시스템의 상태를 검증
TDD에서의 사용	주로 모킹 TDD와 연관됨	전통적인 TDD에서 일반적인 방식
의존성 처리	상호작용을 검증하기 위해 모의 객체를 사용함.	의존성에 대해 실제 인스턴스나 스텁을 사용함.
검증 방식	한 메소드가 다른 메소드를 호출하는지 검증함.	메소드 호출 후 객체의 값이 어떻게 변경되는지 검증함.
용도	객체 설계 / 검증 Objectd-Oriented	코드(로직) 검증 리펙토링
Double(대역) 사용	이해 관계 행동을 위한 객체는 모두 Mock	Real 객체 사용이 곤란한 경우 상태 검증만 할 수 있다면 어떤 double이든 무관
디자인 접근 방식	Outside-in (상위 레이어에서 하위 레이어로) Top-Down	Domain model-out Middle out(중/하위 레이어에서 상위 레이어로) Bottom-up

 

 

 

목(Mock)과 Stub(스텁)의 차이

Stub은 상태 검증을 사용하고, Mock은 동작 검증을 사용한다.
Stub은 테스트 중 이뤄지는 호출에 미리 준비된 답변을 제공하도록 프로그래밍(코딩)하며, 준비된 응답 외에는 검증하지 못한다. Stub은 전통적인 TDD처럼 상태(값)의 검증에 집중한다. 

Mock은 수신할 것으로 예상되는 호출을 검증하며, Mock의 결과 보다는 호출(메서드 Call)이라는 행동 검증에 집중한다.
(물론 Mock의 returnValue를 테스트에 사용해도 되지만) 이로인해 Object-Oriented 설계 중심의 검증에 적합하다. 

 

그 외 double들

dummy : 매개변수를 채우는 용도, 실제 사용되진 않음
Fake : 가짜 객체. 메모리 DB처럼 직을 검증하는데 사용되는 객체. 상용에서는 사용하지 못함

mock : mock library를 이용. 세부 구현은 없음
stub : 나무 그루터기, 몽당연필처럼 짧은 코드 구현이 포함됨
Spy : 일부 정보를 기록함

 

Why call double?
영화에서 위험한 연기를 대신하는 것을 stunt double(대역 배우)라고 하는데 테스트를 위해 실제 객체 역할을 대신한다고 해서 test double 이라고 함

 

Classical and Mockist Testing

Classical Style TDD : 가급적 실제 객체를 사용하지만, 실제 객체를 사용하기 어려운 경우에는 double(대역)을 사용한다. double의 종류는 그다지 중요하지 않으며, 상태(로직, 값, 결과)를 검증할 수 있다면 어떤 double을 사용하는 것도 무방하다.

 

Mockist Style TDD : 행동 기반 테스트가 중요하며 여기서 파생된 것이 BDD(Behavior Driven Development)이다. BDD는 TDD가 디자인 기술로 작동하는 방식에 초점을 맞춰 개발자들이 테스트 주도 개발을 더 잘 배울 수 있도록 돕는 기술. 

 

선택

객체 간의 협업이 쉬운 케이스에서는 고전적인 테스트 방법을 사용하며, 가급적 어떤 double(대역 - Mock, Stub, Spy, Fake, Dummy )도 사용하지 않고, Real 객체를 사용하는 것이 가장 좋다. 

어색한 협업 또는 실제 객체의 행동(Behavior, Method) 호출이 곤란한 케이스(예를 들어 이메일 발송)라면 double을 사용한다. 
이때 행동(메서드 호출)을 검증하는 경우에는 mock을 사용하고, 결과 상태를 사용하는 경우에는 적합한 double을 사용한다. 

Object-Oriented 방식의 클래스 설계를 해 나가는 경우에는 Mockist Testing 방식으로 Mock을 사용하는 것이 적합하다.

 

TDD 기원은 점진적인 설계(구현)를 지원하는 강력한 자동 회귀 테스트를 얻으려는 열망에서 시작되었다.

그 과정에서 실무자들은 테스트 작성이 디자인 프로세스를 크게 개선한다는 사실을 발견했다.  

Mockists(Mock을 사용하여 소프트웨어를 디자인하고 테스트하는 개발자들)는 좋은 소프트웨어 디자인이 무엇인지에 대해 명확한 이념을 가지고 있으며, 이런 디자인 이념을 실천하고 퍼뜨리기 위해 모의 객체를 사용하는 라이브러리를 개발했다. 이 라이브러리는 '좋은 디자인'을 쉽게 이해하고 적용할 수 있도록 돕는다.

즉, Mockist Style = 디자인 설계 및 행동을 검증하며 진행하는 좋은 디자인 스타일 개발 테스트
Classical Style = 상태를 검증하며 진행하는 점진적인 개발 및 강력한 자동 회귀 테스트