モックはスタブではない

通常のテスト

まず、簡単な例を使って2つのスタイルを説明します。（例はJavaですが、原則はどのオブジェクト指向言語でも理解できます。）注文オブジェクトを取得し、倉庫オブジェクトからそれを満たしたいと考えています。注文は非常にシンプルで、1つの製品と数量のみです。倉庫はさまざまな製品の在庫を保有しています。注文に倉庫から在庫を補充するように依頼すると、2つの可能な応答があります。倉庫に注文を満たすのに十分な製品がある場合、注文は満たされ、倉庫の製品の量は適切な量だけ減少します。倉庫に十分な製品がない場合、注文は満たされず、倉庫では何も起こりません。

これらの2つの動作は、いくつかのテストを意味します。これらはかなり従来のJUnitテストのように見えます。

public class OrderStateTester extends TestCase {
  private static String TALISKER = "Talisker";
  private static String HIGHLAND_PARK = "Highland Park";
  private Warehouse warehouse = new WarehouseImpl();

  protected void setUp() throws Exception {
    warehouse.add(TALISKER, 50);
    warehouse.add(HIGHLAND_PARK, 25);
  }
  public void testOrderIsFilledIfEnoughInWarehouse() {
    Order order = new Order(TALISKER, 50);
    order.fill(warehouse);
    assertTrue(order.isFilled());
    assertEquals(0, warehouse.getInventory(TALISKER));
  }
  public void testOrderDoesNotRemoveIfNotEnough() {
    Order order = new Order(TALISKER, 51);
    order.fill(warehouse);
    assertFalse(order.isFilled());
    assertEquals(50, warehouse.getInventory(TALISKER));
  }

xUnitテストは、典型的な4つのフェーズシーケンス（セットアップ、実行、検証、ティアダウン）に従います。この場合、セットアップフェーズは partly setUpメソッド（倉庫のセットアップ）で、partly テストメソッド（注文のセットアップ）で行われます。 order.fillの呼び出しは実行フェーズです。これは、テスト対象のオブジェクトに動作を実行させる段階です。assertステートメントは検証段階であり、実行されたメソッドがタスクを正しく実行したかどうかを確認します。この場合、明示的なティアダウンフェーズはなく、ガベージコレクタが暗黙的にこれを行います。

セットアップ中に、2種類のオブジェクトを組み合わせています。Orderはテスト対象のクラスですが、Order.fillが機能するためには、Warehouseのインスタンスも必要です。この状況では、Orderはテストに焦点を当てているオブジェクトです。テスト指向の人々は、このようなものを指名するために、テスト対象オブジェクトやテスト対象システムなどの用語を使用するのが好きです。どちらの用語も言うには厄介ですが、広く受け入れられている用語なので、我慢して使用します。Meszarosに従って、テスト対象システム、つまり略語SUTを使用します。

そのため、このテストにはSUT（Order）と1つのコラボレーター（warehouse）が必要です。倉庫が必要なのは2つの理由からです。1つはテスト対象の動作を überhaupt 機能させるため（Order.fillは倉庫のメソッドを呼び出すため）、2つ目は検証のためです（Order.fillの結果の1つは倉庫の状態の潜在的な変化であるため）。このトピックをさらに詳しく見ていくと、SUTとコラボレーターを区別することがたくさんあることがわかります。（この記事の以前のバージョンでは、SUTを「プライマリオブジェクト」、コラボレーターを「セカンダリオブジェクト」と呼んでいました。）

このテストスタイルでは、**状態検証**を使用します。つまり、メソッドが実行された後にSUTとそのコラボレーターの状態を調べて、実行されたメソッドが正しく機能したかどうかを判断します。後で見るように、モックオブジェクトは検証に異なるアプローチを可能にします。

モックオブジェクトを使用したテスト

それでは、同じ動作を使用してモックオブジェクトを使用します。このコードでは、モックを定義するためにjMockライブラリを使用しています。jMockはJavaモックオブジェクトライブラリです。他にもモックオブジェクトライブラリはありますが、これはこの手法の創始者によって書かれた最新のライブラリであるため、始めるのに適しています。

public class OrderInteractionTester extends MockObjectTestCase {
  private static String TALISKER = "Talisker";

  public void testFillingRemovesInventoryIfInStock() {
    //setup - data
    Order order = new Order(TALISKER, 50);
    Mock warehouseMock = new Mock(Warehouse.class);
    
    //setup - expectations
    warehouseMock.expects(once()).method("hasInventory")
      .with(eq(TALISKER),eq(50))
      .will(returnValue(true));
    warehouseMock.expects(once()).method("remove")
      .with(eq(TALISKER), eq(50))
      .after("hasInventory");

    //exercise
    order.fill((Warehouse) warehouseMock.proxy());
    
    //verify
    warehouseMock.verify();
    assertTrue(order.isFilled());
  }

  public void testFillingDoesNotRemoveIfNotEnoughInStock() {
    Order order = new Order(TALISKER, 51);    
    Mock warehouse = mock(Warehouse.class);
      
    warehouse.expects(once()).method("hasInventory")
      .withAnyArguments()
      .will(returnValue(false));

    order.fill((Warehouse) warehouse.proxy());

    assertFalse(order.isFilled());
  }

まずtestFillingRemovesInventoryIfInStockに集中してください。後のテストではいくつかのショートカットを使用しているためです。

まず、セットアップフェーズが非常に異なります。まず、データと期待の2つの部分に分かれています。データ部分は、作業に関心のあるオブジェクトを設定します。その意味では、従来のセットアップに似ています。違いは、作成されるオブジェクトにあります。SUTは同じです - 注文です。ただし、コラボレーターは倉庫オブジェクトではなく、モック倉庫です。技術的にはMockクラスのインスタンスです。

セットアップの2番目の部分は、モックオブジェクトに対する期待を作成します。期待は、SUTが実行されたときにモックでどのメソッドが呼び出されるかを示します。

すべての期待が設定されたら、SUTを実行します。実行後、検証を行います。検証には2つの側面があります。以前と同様に、SUTに対してassertを実行します。ただし、モックも検証します。期待どおりに呼び出されたかどうかを確認します。

ここでの重要な違いは、注文が倉庫とのやり取りで正しいことをしたかどうかを検証する方法です。状態検証では、倉庫の状態に対してassertを実行することでこれを行います。モックは**動作検証**を使用します。ここでは、注文が倉庫に対して正しい呼び出しを行ったかどうかを確認します。このチェックは、セットアップ中にモックに何を期待するかを伝え、検証中にモックに自己検証を依頼することで行います。assertを使用してチェックされるのは注文のみであり、メソッドが注文の状態を変更しない場合は、assertは全くありません。

2番目のテストでは、いくつかの異なることを行います。まず、コンストラクタではなくMockObjectTestCaseのmockメソッドを使用して、モックを異なる方法で作成します。これはjMockライブラリの便利なメソッドであり、後でverifyを明示的に呼び出す必要がないことを意味します。便利なメソッドで作成されたモックは、テストの最後に自動的に検証されます。最初のテストでもこれを行うことができましたが、モックを使ったテストの仕組みを示すために、検証をより明示的に示したかったのです。

2番目のテストケースの2番目の違いは、withAnyArgumentsを使用して期待の制約を緩和したことです。これは、最初のテストで倉庫に番号が渡されることをチェックするため、2番目のテストではテストのその要素を繰り返す必要がないためです。注文のロジックを後で変更する必要がある場合、1つのテストのみが失敗するため、テストの移行作業が軽減されます。結局のところ、withAnyArgumentsはデフォルトであるため、完全に省略することもできました。

public class OrderEasyTester extends TestCase {
  private static String TALISKER = "Talisker";
  
  private MockControl warehouseControl;
  private Warehouse warehouseMock;
  
  public void setUp() {
    warehouseControl = MockControl.createControl(Warehouse.class);
    warehouseMock = (Warehouse) warehouseControl.getMock();    
  }

  public void testFillingRemovesInventoryIfInStock() {
    //setup - data
    Order order = new Order(TALISKER, 50);
    
    //setup - expectations
    warehouseMock.hasInventory(TALISKER, 50);
    warehouseControl.setReturnValue(true);
    warehouseMock.remove(TALISKER, 50);
    warehouseControl.replay();

    //exercise
    order.fill(warehouseMock);
    
    //verify
    warehouseControl.verify();
    assertTrue(order.isFilled());
  }

  public void testFillingDoesNotRemoveIfNotEnoughInStock() {
    Order order = new Order(TALISKER, 51);    

    warehouseMock.hasInventory(TALISKER, 51);
    warehouseControl.setReturnValue(false);
    warehouseControl.replay();

    order.fill((Warehouse) warehouseMock);

    assertFalse(order.isFilled());
    warehouseControl.verify();
  }
}

モックとスタブの違い

モックオブジェクトが初めて導入されたとき、多くの人はスタブを使用するという一般的なテストの概念とモックオブジェクトを混同していました。それ以来、人々は違いをよりよく理解しているようです（そして、この論文の以前のバージョンが役立ったことを願っています）。しかし、人々がモックを使用する方法を完全に理解するには、モックと他の種類のテストダブルを理解することが重要です。（「ダブル」？これがあなたにとって新しい用語であっても心配しないでください。数段落待てばすべて明らかになります。）

このようなテストを行う場合、ソフトウェアの1つの要素に一度に焦点を当てています。そのため、単体テストという用語が一般的に使用されます。問題は、単一のユニットを動作させるために、多くの場合、他のユニットが必要になることです。そのため、この例では、ある種の倉庫が必要になります。

上記に示した2つのテストスタイルでは、最初のケースは実際の倉庫オブジェクトを使用し、2番目のケースはモック倉庫を使用します。これはもちろん、実際の倉庫オブジェクトではありません。モックを使用することは、テストで実際の倉庫を使用しない1つの方法ですが、このようなテストで使用される非現実的なオブジェクトには他にも種類があります。

これについて話すための語彙はすぐに混乱します。スタブ、モック、フェイク、ダミーなど、あらゆる種類の言葉が使用されます。この記事では、Gerard Meszarosの本の語彙に従います。誰もが使用するわけではありませんが、良い語彙だと思います。これは私のエッセイなので、どの単語を使用するかを選択できます。

Meszarosは、テスト目的で実際のオブジェクトの代わりに使用されるあらゆる種類の偽のオブジェクトの総称として、**テストダブル**という用語を使用しています。この名前は、映画のスタントダブルの概念に由来しています。（彼の目的の1つは、すでに広く使用されている名前の使用を避けることでした。）Meszarosは、5種類のダブルを定義しました。

• **ダミー**オブジェクトは渡されますが、実際には使用されません。通常、それらはパラメータリストを埋めるためにのみ使用されます。
• **フェイク**オブジェクトは実際に動作する実装を持っていますが、通常、本番環境には適さないショートカットを使用します（インメモリデータベースが良い例です）。
• **スタブ**は、テスト中に実行された呼び出しに対して事前に用意された回答を提供します。通常、テスト用にプログラムされていないものにはまったく応答しません。
• **スパイ**は、呼び出された方法に基づいていくつかの情報を記録するスタブです。この形式の1つは、送信されたメッセージの数を記録する電子メールサービスです。
• **モック**は、ここで説明しているものです。受信することが予想される呼び出しの仕様を形成する期待値で事前にプログラムされたオブジェクトです。

これらの種類のダブルの中で、モックだけが動作検証を主張します。他のダブルは、通常、状態検証を使用できます。モックは、実行フェーズ中は他のダブルのように動作します。SUTに実際の共同作業者と話をしていると信じさせる必要があるためです。しかし、モックはセットアップフェーズと検証フェーズで異なります。

テストダブルをもう少し詳しく調べるには、例を拡張する必要があります。多くの人は、実際のオブジェクトの操作が難しい場合にのみテストダブルを使用します。テストダブルのより一般的なケースは、注文の処理に失敗した場合に電子メールメッセージを送信したいと言った場合です。問題は、テスト中に顧客に実際の電子メールメッセージを送信したくないことです。そのため、代わりに、制御および操作できる電子メールシステムのテストダブルを作成します。

ここで、モックとスタブの違いがわかり始めます。このメール動作のテストを作成する場合、次のような単純なスタブを作成できます。

public interface MailService {
  public void send (Message msg);
}

public class MailServiceStub implements MailService {
  private List<Message> messages = new ArrayList<Message>();
  public void send (Message msg) {
    messages.add(msg);
  }
  public int numberSent() {
    return messages.size();
  }
}                                 

次に、次のようにスタブで状態検証を使用できます。

class OrderStateTester...

  public void testOrderSendsMailIfUnfilled() {
    Order order = new Order(TALISKER, 51);
    MailServiceStub mailer = new MailServiceStub();
    order.setMailer(mailer);
    order.fill(warehouse);
    assertEquals(1, mailer.numberSent());
  }

もちろん、これは非常に単純なテストです。メッセージが送信されたことだけです。正しい人に送信されたか、正しい内容で送信されたかはテストしていませんが、要点を説明するにはこれで十分です。

モックを使用すると、このテストはまったく異なります。

class OrderInteractionTester...

  public void testOrderSendsMailIfUnfilled() {
    Order order = new Order(TALISKER, 51);
    Mock warehouse = mock(Warehouse.class);
    Mock mailer = mock(MailService.class);
    order.setMailer((MailService) mailer.proxy());

    mailer.expects(once()).method("send");
    warehouse.expects(once()).method("hasInventory")
      .withAnyArguments()
      .will(returnValue(false));

    order.fill((Warehouse) warehouse.proxy());
  }
}

どちらの場合も、実際のメールサービスの代わりにテストダブルを使用しています。スタブは状態検証を使用し、モックは動作検証を使用するという違いがあります。

スタブで状態検証を使用するには、検証に役立つスタブにいくつかの追加メソッドを作成する必要があります。その結果、スタブは `MailService` を実装しますが、追加のテストメソッドを追加します。

モックオブジェクトは常に動作検証を使用し、スタブはどちらの方法でも使用できます。Meszarosは、動作検証を使用するスタブをテストスパイと呼んでいます。違いは、ダブルがどのように実行および検証されるかであり、それは自分で調べてみることにします。

古典的テストとモックテスト

これで、2番目の二分法、つまり古典的なTDDとモック主義のTDDの違いを探ることができます。ここで大きな問題は、*いつ*モック（または他のダブル）を使用するかです。

**古典的なTDD**スタイルは、可能であれば実際のオブジェクトを使用し、実際のオブジェクトを使用するのが難しい場合はダブルを使用することです。そのため、古典的なTDDerは実際の倉庫を使用し、メールサービスにはダブルを使用します。ダブルの種類はそれほど重要ではありません。

しかし、**モック主義のTDD**を実践する人は、興味深い動作をするオブジェクトには常にモックを使用します。この場合は、倉庫とメールサービスの両方です。

さまざまなモックフレームワークはモック主義テストを念頭に置いて設計されましたが、多くの古典主義者はダブルを作成するのに役立つと考えています。

モック主義スタイルの重要な派生物は、ビヘイビア駆動開発（BDD）です。BDDは、もともと私の同僚であるDaniel Terhorst-Northによって、TDDが設計手法としてどのように機能するかに焦点を当てることで、人々がテスト駆動開発をよりよく学習できるようにするための手法として開発されました。これにより、テストの名前をビヘイビアに変更して、TDDがオブジェクトの動作について考えるのにどのように役立つかをよりよく探求できるようになりました。BDDはモック主義のアプローチを採用していますが、命名スタイルと分析をその手法に統合したいという願望の両方で、これを拡張しています。この記事との関連性は、BDDがモック主義テストを使用する傾向があるTDDの別のバリエーションであることだけなので、ここではこれ以上説明しません。詳細については、リンクをたどってください。

「古典的」には「デトロイト」スタイル、「モック主義」には「ロンドン」スタイルが使用されることがあります。これは、XPがもともとデトロイトのC3プロジェクトで開発され、モック主義スタイルがロンドンの初期のXP採用者によって開発されたという事実を暗示しています。また、多くのモック主義TDD担当者は、その用語、そして実際には古典的テストとモック主義テストの間に異なるスタイルがあることを意味する用語を嫌っています。彼らは、2つのスタイルの間に有用な区別があるとは考えていません。

違いによる選択

この記事では、状態検証または動作検証/古典的またはモック主義TDDの2つの違いについて説明しました。それらの間で選択を行う際に留意すべき引数は何ですか？まず、状態と動作の検証の選択から始めます。

最初に考慮すべきことはコンテキストです。注文と倉庫のような簡単なコラボレーション、または注文とメールサービスのような厄介なコラボレーションについて考えていますか？

簡単なコラボレーションであれば、選択は簡単です。私が古典的なTDDerであれば、モック、スタブ、またはその他のダブルは使用しません。実際のオブジェクトと状態検証を使用します。私がモック主義のTDDerであれば、モックと動作検証を使用します。まったく決定はありません。

厄介なコラボレーションであれば、私がモック主義者であれば決定はありません。モックと動作検証を使用するだけです。私が古典主義者であれば、選択肢はありますが、どちらを使用しても大した問題ではありません。通常、古典主義者は状況ごとに決定を下し、各状況で最も簡単なルートを使用します。

したがって、見てのとおり、状態と動作の検証は、ほとんどの場合、大きな決定ではありません。本当の問題は、古典的TDDとモック主義TDDの間です。結局のところ、状態と動作の検証の特性は、その議論に影響を与えます。それが私がエネルギーのほとんどを集中するところです。

しかし、その前に、エッジケースを投入させてください。厄介なコラボレーションではない場合でも、状態検証を実際に使用するのが難しいことに出くわすことがあります。これの素晴らしい例はキャッシュです。キャッシュのポイントは、状態からキャッシュがヒットしたかミスしたかを判断できないことです。これは、筋金入りの古典的なTDDerでさえ、動作検証が賢明な選択となるケースです。どちらの方向にも他にも例外があると思います。

古典的/モック主義の選択を掘り下げると、考慮すべき要素がたくさんあるので、それらを大まかなグループに分けました。

古典主義者とモック主義者のどちらであるべきか？

この質問に自信を持って答えるのは難しいと感じています。個人的には、私はいつも昔ながらの古典的なTDDerであり、これまでのところ変更する理由が見つかりません。モック主義TDDの説得力のある利点が見当たらず、テストを実装に結合することの影響が懸念されます。

これは、モック主義プログラマーを観察したときに特に印象的でした。テストを作成している間、どのように行われるかではなく、動作の結果に焦点を当てるという事実が本当に気に入っています。モック主義者は、期待を書くためにSUTがどのように実装されるかについて常に考えています。これは私には本当に不自然に感じます。

また、おもちゃ以上のものに対してモック主義TDDを試していないという欠点にも悩まされています。テスト駆動開発自体から学んだように、真剣に試してみないとテクニックを判断するのは難しいことがよくあります。私は、非常に満足していて、モック主義者に確信を持っている多くの優れた開発者を知っています。ですから、私はまだ確信を持った古典主義者ですが、どちらの議論もできる限り公平に提示して、自分で判断できるようにしたいと思います。

そのため、モック主義テストが魅力的に聞こえる場合は、試してみることをお勧めします。モック主義TDDが改善することを目的としている領域のいくつかで問題が発生している場合は、特に試してみる価値があります。ここでは2つの主要な領域があります。1つは、テストがクリーンに中断されず、問題の場所がわからないために、テストの失敗時にデバッグに多くの時間を費やしている場合です。（細かい粒度のクラスターで古典的なTDDを使用することで、これを改善することもできます。）2つ目の領域は、オブジェクトに十分な動作が含まれていない場合、モック主義テストによって開発チームがより多くの動作豊富なオブジェクトを作成するようになる可能性があることです。

最後に

ユニットテスト、xunitフレームワーク、そしてテスト駆動開発への関心が高まるにつれ、モックオブジェクトに遭遇する人がますます増えています。多くの人は、モックオブジェクトフレームワークについて少し学びますが、その基礎にあるモッキスト/クラシカルの対立を完全に理解しているわけではありません。どちらの立場に立つかは別として、この見解の違いを理解することは有益だと思います。モックフレームワークを使いこなすためにモッキストである必要はありませんが、ソフトウェアの多くの設計決定を導く考え方を理解することは有用です。

この記事の目的は、これらの違いを指摘し、それらの間のトレードオフを明確にすることでした。そして、今もそうです。モッキストの考え方については、私が説明できた以上のものがあり、特にデザインスタイルへの影響があります。今後数年間で、このテーマに関するより多くの著作物が出版され、コードを書く前にテストを書くという魅力的な結果についての理解が深まることを願っています。