クラスをユニットテストしましたが、統合テストを開始する方法を教えてください。

MailChimpRecipientと呼ばれるMailChimpリストの受信者を管理するクラスを作成しました。サードパーティのAPIラッパーであるMCAPIクラスを使用します。

http://apidocs.mailchimp.com/api/1.3/ http://apidocs.mailchimp.com/api/downloads/

MCAPIオブジェクトをMailChimpRecipientオブジェクトのコンストラクターに渡すため、PHPUnitを使用して、独自のクラスのすべてのロジックをテストする単体テストを作成しました（MCAPIクラスはテストしていません）。コードカバレッジは100％で、すべてのテストに合格しています。これは、MCAPIオブジェクトのモックとスタブ化によって行われます。

次のステップでは、PHPUnitを使用して統合テストを作成し、実際のMCAPIオブジェクトを使用してMailChimpRecipientフィクスチャを構築し、実際のMailChimpリストを使用するように設定しました。

私は、次のように、基本的にオブジェクトのパブリックインターフェイスに対してテストを実行する統合テストだと思うものを書きました。

public function testAddedRecipientCanBeFound()
{
    $emailAddress = 'fred@fredsdomain.com';
    $forename = 'Fred';
    $surname = 'Smith';

    // First, delete the email address if it is already on the list
    $oldRecipient = $this->createRecipient();
    if($oldRecipient->find($emailAddress))
    {
        $oldRecipient->delete();
    }
    unset($oldRecipient);

    // Add the recipient using the test data
    $newRecipient = $this->createRecipient();
    $newRecipient->setForename($forename);
    $newRecipient->setSurname($surname);
    $newRecipient->setEmailAddress($emailAddress);
    $newRecipient->add();
    unset($newRecipient);

    // Assert that the recipient can be found using the same email address
    $this->assertTrue($this->_recipient->find($emailAddress));
}

「統合」テストでは、クラスの内部はテストされません。実際のMCAPIオブジェクトが与えられたときに、アドバタイズされたとおりに動作することを確認するだけです。

これは正しいです？これは、統合テストを実行する最良の方法ですか？結局のところ、内部テストは単体テストでテストされています。統合テストは、その動作が宣伝されている方法に従って、実際に機能することをテストするためにあると思いますか？

さらに一歩進めるために、MailChimpRecipientクラスはインターフェイスを実装します。これは他のクラスによっても実装されます。アイデアは、ファクトリを使用して、さまざまなタイプのメーリングリスト受信者オブジェクトをコードに渡すことです。これらのオブジェクトはすべて、異なるメーリングリストプロバイダを使用しても同じことを行います。私の統合テストはそのインターフェースをテストするので、インターフェースを実装するすべてのクラスに使用するのはどうですか？その後、将来、交換可能に使用される新しいクラスを設計する場合、プロジェクトに挿入する前に同じ統合テストを実行できます。

これは理にかなっていますか？単体テストはオブジェクトの内部をテストし、統合テストは広告されたとおりに動作することを確認しますか？

コードをテストするときは、次の3つの領域に注意する必要があります。

• シナリオテスト
• 機能テスト
• 単体テスト

通常、各カテゴリにあるテストの量はピラミッドの形になります。つまり、下部にたくさんのユニットテスト、中央にいくつかの機能テスト、いくつかのシナリオテストがあります。

単体テストでは、テスト対象のクラスが使用するすべてをモックアウトし、それを完全に分離してテストします（これは、テスト中に置き換えることができるように、クラス内でインジェクションを通じてすべての依存関係を取得することを確認することが重要な理由です）

単体テストでは、すべての可能性、つまり「ハッピーパス」だけでなく、すべてのエラー状態もテストします。

すべてのユニットが単独で動作することを完全に確信している場合は、結合したときにユニットも動作することを確認するために、いくつかのテスト（機能テスト）を作成します。次に、すべての機能モジュール間の配線をテストするシナリオテストを作成します。

たとえば、車をテストしているとします。

車全体を組み立てて、ドライバーとして考えられるすべての状態をチェックすることもできますが、それは本当に難しいことです。

代わりに、すべての可能性を使用してエンジンの小さな部分をテストします（ユニットテスト）

次に、エンジン全体（車とは別）をテストします。これは機能テストになります。

最後のテストとして、鍵を入れて車を始動し、駐車場まで運転します。それが機能している場合は、すべての部品（バッテリー、燃料、エンジンなど）が接続されていることを知っており、それらを単独でテストしたので、車全体が正しく機能していることを確認できます。

したがって、あなたの場合、すべてのエラー条件とユニットテストのハッピーパスをテストし、配線が正しいかどうかを確認するために「実際のコンポーネント」を使用したエンドツーエンドのテストのみが必要であることを知っています。

他のいくつかのポイント、

• 単体テストで条件付きロジックを使用しないでください。クリーンアップする必要がある場合、何らかのグローバルステートとテストを使用すると、突然互いに影響を与える可能性があります。
• テストに関係のないデータは指定しないでください。名前または姓を変更すると、テストは失敗しますか？おそらくそれが重要なのは電子メールアドレスだからではなく、テストで明示的に言及しているからではありません。テストデータを構築するビルダーパターンを見て、本当に重要なことを明示してください。