# Mocks aren't stubs

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

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

[상태 기반 테스트](https://wiki.g15e.com/pages/State-based%20test.txt)의 단점은 테스트 픽스쳐가 너무 번잡해진다는 점이고, [인터랙션 기반 테스트](https://wiki.g15e.com/pages/Interaction-based%20test.txt)의 단점은 테스트 코드와 프러덕션 코드 사이의 <커플링>이 지나치게 강해진다는 점. <마틴 파울러> 자신은 [State-based test](https://wiki.g15e.com/pages/State-based%20test.txt)를 선호한다고.

## Test double의 다양한 종류

> Meszaros uses the term **Test Double** as the generic term for any kind of pretend object used in place of a real object for testing purposes. The name comes from the notion of a Stunt Double in movies. (One of his aims was to avoid using any name that was already widely used.) Meszaros then defined five particular kinds of double:
>
> - **Dummy** objects are passed around but never actually used. Usually they are just used to fill parameter lists.
> - **Fake** objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in-memory database is a good example).
> - **Stubs** provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test.
> - **Spies** are stubs that also record some information based on how they were called. One form of this might be an email service that records how many messages it was sent.
> - **Mocks** are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.
> 
> Of these kinds of doubles, only mocks insist upon behavior verification.

## Classical and Mockist Testing

> The **classical TDD** style is to use real objects if possible and a double if it's awkward to use the real thing. So a classical TDDer would use a real warehouse and a double for the mail service. The kind of double doesn't really matter that much.
>
> A **mockist TDD** practitioner, however, will always use a mock for any object with interesting behavior. In this case for both the warehouse and the mail service. …
>
> An important offshoot of the mockist style is that of [Behavior-driven development](https://wiki.g15e.com/pages/Behavior-driven%20development.txt).