モックとスタブの違い

Martin FowlerいわくMocks Aren't Stubs（2007年）

テストの方式が違うという主張

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.

つねにテストダブルを使うスタイル

TDDでモックをどうするのか問題

mockとstubを使ったテストの例が書いてある

stubは状態(state)検証

mailerをstubした場合

assertEquals(1, mailer.numberSent());

mockは動作（behavior)検証

mailerをmockした場合、呼び出されるモックはすべて期待動作を書く

code:java

mailer.expects(once()).method("send");

stubでもこれはできて、spyと呼ばれる

が、classical TDDでもむずかったらテストダブルを使うのでこの差は問題ではない

state versus behavior verification is mostly not a big decision. The real issue is between classic and mockist TDD.

Fowlerはこの時点ではclassical TDDで、全てにモックを使う場合だと結合したときに問題が起きるのではないかと懸念している

ただしmockist TDDを大きなプロダクトでやった経験はないという点は認めている

mockist TDDを試す価値があるパターン

1. テストがバグっていて問題箇所が不明。失敗した場合にデバッグに時間がかかる

ただし、classical TDDでも細かな分割をすれば可能

2. オブジェクトに十分な振る舞いが含まれていない場合

mockist testing may encourage the development team to create more behavior rich objects.

キャッシュがヒットしたか失敗したかは状態から判断できない