(http://www.shinetech.com/display/www/What+Are+Mock+Objects%3F)
객체지향 프로그램에서 각 객체는 다른 객체들과 상호작용을 한다.
다음과 같은 그림으로 이를 표현할 수 있다.
Mock Object의 기본 사상은 객체를 unit test할 때 객체가 상호작용하는 collaborator들을 mock collaborator로 변경하는 것이다.
Stub과 다른 점은 아래와 같다.
Mock Objects test themselves
Mock 객체는 테스트 대상 객체에 의해 자신이 적절한 시기에 적절한 방식으로 호출되었는지 조사한다.
Stub은 일반적으로 stubbed data를 단순 반환한다.
Mock Objects are generally extremely lightweight
각 테스트에서 완전히 다른 Mock 인스턴스들이 설정되어야 하는 경우가 있다. Stub은 상대적으로 heavyweight로써 테스트에 재사용된다.
Mock 객체 사용을 위한 디자인 고려 사항은 아래와 같다.
Everything by Interfaces
Dependency Injection
객체의 collaborator는 객체에 전달 되어야 한다. 즉 객체는 자기 자신이 collaborator를 얻지 말아야 한다. 이러한 디자인 기법을 "dependency injection" 또는 "inversion or control"이라고 한다. 이 기법의 자세한 설명은 마틴 파울러의 기사(http://www.martinfowler.com/articles/injection.html)를 참고하기 바란다.
언제 Mock Object를 사용하는 것이 유용한가 ?
Mock의 가장 주요한 잇점은 collaborator를 mock으로 대체함으로써 collaborator 사용을 위해 필요할 수 있는 복잡한 상태 설정이 필요 없게 된다는 점이다. 예를 들어 XML에서 데이터를 가져와서 데이터베이스에 insert하는 비지니스 로직을 고려해 보자. 비지니스 로직을 테스트 할 때 개발자는 XML 파일, 데이터베이스 처리를 위한 복잡한 설정, 데이터베이스 테이블의 내용 조사 등의 작업을 하지 않기를 원할 것이다. 개발자가 원하는 것은 비지니스 로직이 XML 파서, 데이터베이스 계층과 올바로 상호작용하는지를 테스트 하는 것이다. 이러한 경우 개발자는 XML Parser, 데이터베이스 상호작용을 위한 인터페이스를 정의하고 Mock으로 대체함으로써 비지니스 로직만 테스트할 수 있게 된다. 주의할 점은 Mock Object는 unit test를 위한 도구이지 integration test, functional test를 위한 도구가 아니라는 점이다. | 
