実践的なテストピラミッド

機能

アプリケーションの機能はシンプルです。3つのエンドポイントを持つRESTインターフェースを提供します。

高レベル構造

高レベルでは、システムは次の構造になっています。

図3：マイクロサービスシステムの高レベル構造

マイクロサービスは、HTTP経由で呼び出すことができるRESTインターフェースを提供します。一部のエンドポイントでは、サービスはデータベースから情報を取得します。他の場合、サービスはHTTP経由で外部の気象APIを呼び出して、現在の気象条件を取得して表示します。

内部アーキテクチャ

内部的には、SpringサービスはSpringに典型的なアーキテクチャを備えています。

図4：マイクロサービスの内部構造

• `Controller` クラスは*REST*エンドポイントを提供し、*HTTP*リクエストとレスポンスを処理します
• `Repository` クラスは*データベース*とインターフェースし、永続ストレージへのデータの書き込みと読み取りを処理します
• `Client` クラスは他のAPIと通信します。この場合は、darksky.net気象APIから*HTTPS*経由で*JSON*を取得します
• ドメインクラスは、ドメインロジック（公平を期すために言えば、この場合は非常に些細なものですが）を含む、ドメインモデルを捉えます。

経験豊富なSpring開発者は、ここで頻繁に使用される層が欠落していることに気付くかもしれません。ドメイン駆動設計に影響を受けて、多くの開発者は`サービス`クラスで構成される*サービス層*を構築します。このアプリケーションにはサービス層を含めないことにしました。1つの理由は、アプリケーションが単純であるため、サービス層は不要な間接レベルになるからです。もう1つの理由は、サービス層を使いすぎている人が多いと思うからです。ビジネスロジック全体がサービス クラス内にカプセル化されているコードベースによく遭遇します。ドメインモデルは、振る舞いではなく、データの層にすぎなくなります（貧血ドメインモデル）。重要でないアプリケーションの場合、これはコードを適切に構造化してテスト可能にするための多くの可能性を無駄にし、オブジェクト指向の力を最大限に活用していません。

私たちのリポジトリは単純明快で、シンプルなCRUD機能を提供します。コードをシンプルにするために、Spring Dataを使用しました。Spring Dataは、独自に実装する代わりに使用できる、シンプルで汎用的なCRUDリポジトリ実装を提供します。また、本番環境のように実際のPostgreSQLデータベースを使用する代わりに、テスト用にインメモリデータベースを起動します。

コードベースを見て、内部構造に慣れてください。次のステップであるアプリケーションのテストに役立ちます。

ユニットとは何か？

単体テストのコンテキストで*「ユニット」*が何を意味するのかを3人の異なる人に尋ねると、おそらく4つの異なる、わずかにニュアンスのある回答が得られるでしょう。ある程度は、それはあなた自身の定義の問題であり、標準的な答えがないことは問題ありません。

関数型言語で作業している場合、*ユニット*は単一の関数になる可能性が高くなります。単体テストは、さまざまなパラメーターを使用して関数を呼び出し、期待値が返されることを確認します。オブジェクト指向言語では、ユニットは単一のメソッドからクラス全体まで及ぶ可能性があります。

社交的と孤独

テスト対象のコラボレーター（たとえば、テスト対象のクラスによって呼び出される他のクラス）はすべて、*モック*または*スタブ*に置き換えて、完全な分離を実現し、副作用や複雑なテスト設定を回避する必要があると主張する人もいます。低速であるか、大きな副作用があるコラボレーター（たとえば、データベースにアクセスしたり、ネットワーク呼び出しを行うクラス）のみをスタブまたはモックする必要があると主張する人もいます。

場合によっては、これら2種類のテストは、すべてのコラボレーターをスタブするテストの**孤独な単体テスト**と、実際のコラボレーターとの通信を許可するテストの**社交的な単体テスト**としてラベル付けされます（Jay Fieldsの単体テストを効果的に使用するはこれらの用語を作り出しました）。時間があれば、さまざまな考え方の長所と短所について詳しく読むことができます。

結局のところ、孤独な単体テストと社交的な単体テストのどちらを選択するかは重要ではありません。重要なのは、自動テストを書くことです。個人的には、常に両方のアプローチを使用しています。実際のコラボレーターを使用するのが難しい場合は、モックとスタブを惜しみなく使用します。実際のコラボレーターを巻き込むことでテストへの自信が高まると感じる場合は、サービスの最も外側の部分のみをスタブします。

モッキングとスタビング

簡単に言えば、それは、実際の物（たとえば、クラス、モジュール、または関数）をその物の偽のバージョンに置き換えることを意味します。偽のバージョンは本物のように見え、動作しますが（同じメソッド呼び出しに応答します）、単体テストの開始時に自分で定義した既製の応答で応答します。

テストダブルの使用は、単体テストに限定されません。より精巧なテストダブルを使用して、システム全体の一部を制御された方法でシミュレートできます。ただし、単体テストでは、多くの最新の言語とライブラリでモックとスタブを簡単に設定できるため、多くのモックとスタブに遭遇する可能性が高くなります（社交的な開発者か孤独な開発者かによって異なります）。

テクノロジーの選択に関係なく、言語の標準ライブラリまたは一般的なサードパーティライブラリが、モックを設定するための洗練された方法を提供する可能性が高くなります。また、独自のモックを最初から作成する場合でも、実際のものと同じシグネチャを持つ偽のクラス/モジュール/関数を作成し、テストで偽を設定するだけです。

単体テストは非常に高速に実行されます。まともなマシンでは、数分以内に数千の単体テストを実行できます。コードベースの小さな部分を個別にテストし、データベース、ファイルシステムへのアクセス、またはHTTPクエリの発行を回避して（これらの部分にモックとスタブを使用することにより）、テストを高速に保ちます。

単体テストの作成に慣れると、作成がますます流暢になります。外部のコラボレーターをスタブアウトし、入力データを設定し、テスト対象を呼び出し、返された値が期待どおりであることを確認します。テスト駆動開発を調べて、単体テストで開発をガイドします。正しく適用すれば、優れた流れに入り、優れた保守性の高い設計を考案しながら、包括的で完全に自動化されたテストスイートを自動的に生成するのに役立ちます。それでも、万能薬ではありません。さあ、本当のチャンスを与えて、それがあなたに適しているかどうかを確認してください。

何をテストすべきか？

単体テストの良い点は、機能や内部構造のどのレイヤーに属しているかに関係なく、すべての本番コードクラスに対して作成できることです。リポジトリ、ドメインクラス、またはファイルリーダーを単体テストできるのと同じように、コントローラーを単体テストできます。**本番クラスごとに1つのテストクラス**の経験則に従うだけで、順調に開始できます。

単体テストクラスは、少なくとも**クラスの*パブリック*インターフェイスをテストする**必要があります。プライベートメソッドは、別のテストクラスから呼び出すことができないため、とにかくテストできません。*保護*または*パッケージプライベート*はテストクラスからアクセスできます（テストクラスのパッケージ構造が本番クラスと同じである場合）が、これらのメソッドをテストすると行き過ぎになる可能性があります。

単体テストの作成には微妙な境界線があります。重要なコードパスがすべてテストされていること（ハッピーパスとエッジケースを含む）を確認する必要があります。同時に、実装に密接に結びついていてはなりません。

それはなぜですか？

本番コードに近すぎるテストはすぐに面倒になります。本番コードをリファクタリングするとすぐに（簡単な要約：リファクタリングとは、外部から見える動作を変更せずにコードの内部構造を変更することを意味します）、単体テストは失敗します。

このようにして、単体テストの大きな利点の1つである、コード変更のセーフティネットとしての役割を失います。あなたはむしろ、リファクタリングするたびにこれらの愚かなテストが失敗することにうんざりし、役に立つよりも多くの作業を引き起こします。そして、この愚かなテストのアイデアは誰のものだったのでしょうか？

代わりに何をしますか？単体テスト内で内部コード構造を反映しないでください。代わりに、観察可能な動作をテストします。次のように考えてください

値`x`と`y`を入力すると、結果は`z`になりますか？

の代わりに

`x`と`y`を入力すると、メソッドは最初にクラスAを呼び出し、次にクラスBを呼び出し、次にクラスAの結果とクラスBの結果を返しますか？

プライベートメソッドは、一般的に実装の詳細と見なされる必要があります。そのため、テストする必要すらありません。

単体テスト（またはTDD）の反対者が、高いテストカバレッジを実現するためにすべてのメソッドをテストする必要があるため、単体テストの作成が無意味な作業になると主張しているのをよく耳にします。彼らはしばしば、熱心すぎるチームリーダーが、100％のテストカバレッジを実現するために、ゲッターとセッター、およびその他すべての種類の些細なコードの単体テストを作成することを強制したシナリオを引用します。

それは間違っています。

はい、*パブリックインターフェイスをテストする*必要があります。しかし、さらに重要なのは、**些細なコードをテストしない**ことです。心配しないで、ケントベックは大丈夫だと言いました。単純な*ゲッター*または*セッター*、またはその他の些細な実装（たとえば、条件付きロジックがない）をテストしても何も得られません。時間を節約してください。それはあなたが参加できるもう1つの会議です。万歳！

テスト構造

すべてのテストに適した構造（これは単体テストに限定されません）は次のとおりです。

1. テストデータを設定する
2. テスト対象のメソッドを呼び出す
3. 期待される結果が返されることをアサートする

この構造を覚えるための素晴らしいニーモニックがあります： *「準備、実行、アサート」*。使用できるもう1つは、BDDからヒントを得ています。それは*「given」*、*「when」*、*「then」*のトライアドであり、*given*はセットアップ、*when*はメソッド呼び出し、*then*はアサーション部分を反映しています。

このパターンは、他のより高レベルのテストにも適用できます。いずれの場合も、テストが読みやすく、一貫性を保つことができます。その上、この構造を念頭に置いて作成されたテストは、より短く、より表現力豊かになる傾向があります。

ユニットテストの実装

何をテストし、ユニットテストをどのように構成するかを理解したので、実際の例を確認できます。

ExampleControllerクラスの簡略版を見てみましょう

@RestController
public class ExampleController {

    private final PersonRepository personRepo;

    @Autowired
    public ExampleController(final PersonRepository personRepo) {
        this.personRepo = personRepo;
    }

    @GetMapping("/hello/{lastName}")
    public String hello(@PathVariable final String lastName) {
        Optional<Person> foundPerson = personRepo.findByLastName(lastName);

        return foundPerson
                .map(person -> String.format("Hello %s %s!",
                        person.getFirstName(),
                        person.getLastName()))
                .orElse(String.format("Who is this '%s' you're talking about?",
                        lastName));
    }
}

hello(lastname)メソッドのユニットテストは次のようになります

public class ExampleControllerTest {

    private ExampleController subject;

    @Mock
    private PersonRepository personRepo;

    @Before
    public void setUp() throws Exception {
        initMocks(this);
        subject = new ExampleController(personRepo);
    }

    @Test
    public void shouldReturnFullNameOfAPerson() throws Exception {
        Person peter = new Person("Peter", "Pan");
        given(personRepo.findByLastName("Pan"))
            .willReturn(Optional.of(peter));

        String greeting = subject.hello("Pan");

        assertThat(greeting, is("Hello Peter Pan!"));
    }

    @Test
    public void shouldTellIfPersonIsUnknown() throws Exception {
        given(personRepo.findByLastName(anyString()))
            .willReturn(Optional.empty());

        String greeting = subject.hello("Pan");

        assertThat(greeting, is("Who is this 'Pan' you're talking about?"));
    }
}

JavaのデファクトスタンダードのテストフレームワークであるJUnitを使用してユニットテストを作成しています。Mockitoを使用して、実際のPersonRepositoryクラスをテスト用のスタブに置き換えます。このスタブを使用すると、スタブ化されたメソッドがこのテストで返す必要がある既定の応答を定義できます。スタブを使用すると、テストがよりシンプルで予測可能になり、テストデータを簡単に設定できます。

準備、実行、アサートの構造に従って、2つのユニットテスト（肯定的なケースと、検索対象の人物が見つからないケース）を作成します。最初の肯定的なテストケースは、新しいpersonオブジェクトを作成し、lastNameパラメータの値として"Pan"を使用して呼び出されたときに、このオブジェクトを返すようにモックリポジトリに指示します。次に、テスト対象のメソッドを呼び出します。最後に、応答が期待される応答と等しいことをアサートします。

2番目のテストも同様に機能しますが、テスト対象のメソッドが指定されたパラメータの人物を見つけられないシナリオをテストします。

データベース統合

PersonRepositoryは、コードベースで唯一のリポジトリクラスです。Spring Dataに依存しており、実際の実装はありません。CrudRepositoryインターフェースを拡張し、単一のメソッドヘッダーを提供するだけです。残りはSpringマジックです。

public interface PersonRepository extends CrudRepository<Person, String> {
    Optional<Person> findByLastName(String lastName);
}

CrudRepositoryインターフェースを使用すると、Spring Bootは、findOne、findAll、save、update、およびdeleteメソッドを備えた完全に機能するCRUDリポジトリを提供します。カスタムメソッド定義（findByLastName()）はこの基本機能を拡張し、姓でPersonを取得する方法を提供します。Spring Dataは、メソッドの戻り値の型とそのメソッド名を分析し、命名規則に照らしてメソッド名をチェックして、何をするかを判断します。

Spring Dataはデータベースリポジトリの実装の面倒な作業を行いますが、それでもデータベース統合テストを作成しました。これはフレームワークのテストであり、テストしているのは私たちのコードではないため、避けるべきだと主張するかもしれません。それでも、ここに少なくとも1つの統合テストを用意することが重要だと考えています。まず、カスタムのfindByLastNameメソッドが実際に期待どおりに動作することをテストします。次に、リポジトリがSpringの配線を正しく使用し、データベースに接続できることを証明します。

（PostgreSQLデータベースをインストールしなくても）マシンでテストを実行しやすくするために、テストはインメモリH2データベースに接続します。

build.gradleファイルにH2をテスト依存関係として定義しました。テストディレクトリのapplication.propertiesは、spring.datasourceプロパティを定義していません。これは、Spring Dataにインメモリデータベースを使用するように指示します。クラスパスでH2が見つかるため、テストの実行時に単純にH2を使用します。

intプロファイルで実際のアプリケーションを実行する場合（たとえば、環境変数としてSPRING_PROFILES_ACTIVE=intを設定することにより）、application-int.propertiesで定義されているPostgreSQLデータベースに接続します。

それは、知って理解するには非常に多くのSpringの仕様です。そこに到達するには、多くのドキュメントを詳しく調べる必要があります。結果のコードは一見簡単ですが、Springの詳細を知らないと理解するのは困難です。

その上、インメモリデータベースを使用することは危険なビジネスです。結局のところ、統合テストは、本番環境とは異なるタイプのデータベースに対して実行されます。Springマジックとシンプルなコードを、明示的ではるかに冗長な実装よりも好むかどうか、自分で判断してください。

説明はこれで十分です。Personをデータベースに保存し、姓で検索する簡単な統合テストを次に示します

@RunWith(SpringRunner.class)
@DataJpaTest
public class PersonRepositoryIntegrationTest {
    @Autowired
    private PersonRepository subject;

    @After
    public void tearDown() throws Exception {
        subject.deleteAll();
    }

    @Test
    public void shouldSaveAndFetchPerson() throws Exception {
        Person peter = new Person("Peter", "Pan");
        subject.save(peter);

        Optional<Person> maybePeter = subject.findByLastName("Pan");

        assertThat(maybePeter, is(Optional.of(peter)));
    }
}

統合テストは、ユニットテストと同じ準備、実行、アサート構造に従っていることがわかります。これが普遍的な概念だと言ったじゃないですか！

独立したサービスとの統合

マイクロサービスは、気象REST APIであるdarksky.netと通信します。もちろん、サービスがリクエストを送信し、レスポンスを正しく解析することを確認したいと考えています。

自動テストを実行するときに、実際のdarkskyサーバーにアクセスすることは避けたいと考えています。無料プランのクォータ制限は、その理由の一部にすぎません。本当の理由は分離です。テストは、darksky.netの素晴らしい人々が何をしているかに関係なく、独立して実行される必要があります。マシンがdarkskyサーバーにアクセスできない場合や、darkskyサーバーがメンテナンスのためにダウンしている場合でもです。

統合テストの実行中に独自の偽のdarkskyサーバーを実行することで、実際のdarkskyサーバーへのアクセスを回避できます。これは非常に大変な作業のように聞こえるかもしれません。Wiremockのようなツールのおかげで、それは簡単です。これを見てください

@RunWith(SpringRunner.class)
@SpringBootTest
public class WeatherClientIntegrationTest {

    @Autowired
    private WeatherClient subject;

    @Rule
    public WireMockRule wireMockRule = new WireMockRule(8089);

    @Test
    public void shouldCallWeatherService() throws Exception {
        wireMockRule.stubFor(get(urlPathEqualTo("/some-test-api-key/53.5511,9.9937"))
                .willReturn(aResponse()
                        .withBody(FileLoader.read("classpath:weatherApiResponse.json"))
                        .withHeader(CONTENT_TYPE, MediaType.APPLICATION_JSON_VALUE)
                        .withStatus(200)));

        Optional<WeatherResponse> weatherResponse = subject.fetchWeather();

        Optional<WeatherResponse> expectedResponse = Optional.of(new WeatherResponse("Rain"));
        assertThat(weatherResponse, is(expectedResponse));
    }
}

Wiremockを使用するには、固定ポート（`8089`）で`WireMockRule`をインスタンス化します。DSLを使用して、Wiremockサーバーをセットアップし、リッスンするエンドポイントを定義し、応答するべき固定レスポンスを設定できます。

次に、テストしたいメソッド、つまりサードパーティサービスを呼び出すメソッドを呼び出し、結果が正しく解析されているかどうかを確認します。

テストが、実際の*darksky* APIの代わりに偽のWiremockサーバーを呼び出すべきことをどのように認識しているかを理解することが重要です。秘密は、`src/test/resources`に含まれる`application.properties`ファイルにあります。これは、Springがテストを実行するときにロードするプロパティファイルです。このファイルでは、APIキーやURLなどの設定を、テストの目的に適した値（たとえば、実際のサーバーではなく偽のWiremockサーバーを呼び出すなど）で上書きします。

weather.url = http://localhost:8089

ここで定義するポートは、テストで`WireMockRule`をインスタンス化するときに定義するポートと同じである必要があることに注意してください。テストで実際の天気APIのURLを偽のURLに置き換えることは、`WeatherClient`クラスのコンストラクターにURLを注入することで可能になります。

@Autowired
public WeatherClient(final RestTemplate restTemplate,
                     @Value("${weather.url}") final String weatherServiceUrl,
                     @Value("${weather.api_key}") final String weatherServiceApiKey) {
    this.restTemplate = restTemplate;
    this.weatherServiceUrl = weatherServiceUrl;
    this.weatherServiceApiKey = weatherServiceApiKey;
}

このようにして、`WeatherClient`に、アプリケーションプロパティで定義した`weather.url`プロパティから`weatherUrl`パラメータの値を読み取るように指示します。

Wiremockのようなツールを使用すると、個別のサービスの*狭義の統合テスト*を簡単に記述できます。残念ながら、このアプローチには欠点があります。セットアップした偽のサーバーが実際のサーバーのように動作することをどのように保証できるでしょうか？現在の実装では、個別のサービスがAPIを変更しても、テストは合格する可能性があります。今は、`WeatherClient`が偽のサーバーから送信されたレスポンスを解析できることをテストしているだけです。それは始まりですが、非常に脆いです。*エンドツーエンドテスト*を使用して、偽のサービスを使用する代わりに実際のサービスのテストインスタンスに対してテストを実行すると、この問題は解決しますが、テストサービスの可用性に依存することになります。幸いなことに、このジレンマに対するより良い解決策があります。偽のサーバーと実際のサーバーに対してコントラクトテストを実行することで、統合テストで使用する偽のサーバーが忠実なテストダブルであることを保証できます。次に、これがどのように機能するかを見てみましょう。

コンシューマーテスト（自チーム）

私たちのマイクロサービスは天気APIを使用します。そのため、マイクロサービスと気象サービス間の契約（API）に対する期待を定義する**コンシューマーテスト**を作成するのは私たちの責任です。

最初に、`build.gradle`にpactコンシューマーテストを作成するためのライブラリを含めます。

testCompile('au.com.dius:pact-jvm-consumer-junit_2.11:3.5.5')

このライブラリのおかげで、コンシューマーテストを実装し、pactのモックサービスを使用できます。

@RunWith(SpringRunner.class)
@SpringBootTest
public class WeatherClientConsumerTest {

    @Autowired
    private WeatherClient weatherClient;

    @Rule
    public PactProviderRuleMk2 weatherProvider =
            new PactProviderRuleMk2("weather_provider", "localhost", 8089, this);

    @Pact(consumer="test_consumer")
    public RequestResponsePact createPact(PactDslWithProvider builder) throws IOException {
        return builder
                .given("weather forecast data")
                .uponReceiving("a request for a weather request for Hamburg")
                    .path("/some-test-api-key/53.5511,9.9937")
                    .method("GET")
                .willRespondWith()
                    .status(200)
                    .body(FileLoader.read("classpath:weatherApiResponse.json"),
                            ContentType.APPLICATION_JSON)
                .toPact();
    }

    @Test
    @PactVerification("weather_provider")
    public void shouldFetchWeatherInformation() throws Exception {
        Optional<WeatherResponse> weatherResponse = weatherClient.fetchWeather();
        assertThat(weatherResponse.isPresent(), is(true));
        assertThat(weatherResponse.get().getSummary(), is("Rain"));
    }
}

よく見ると、`WeatherClientConsumerTest`は`WeatherClientIntegrationTest`と非常によく似ていることがわかります。サーバースタブにWiremockを使用する代わりに、今回はPactを使用します。実際、コンシューマーテストは統合テストとまったく同じように機能します。実際のサードパーティサーバーをスタブに置き換え、期待されるレスポンスを定義し、クライアントがレスポンスを正しく解析できることを確認します。この意味で、`WeatherClientConsumerTest`はそれ自体が狭い統合テストです。wiremockベースのテストよりも優れている点は、このテストが実行されるたびに*pactファイル*（`target/pacts/&pact-name>.json`にあります）が生成されることです。このpactファイルは、特別なJSON形式でコントラクトに対する期待を記述しています。このpactファイルを使用して、スタブサーバーが実際のサーバーのように動作することを確認できます。pactファイルを取得して、インターフェースを提供するチームに渡すことができます。彼らは、このpactファイルを取得し、そこに定義されている期待を使用してプロバイダーテストを作成します。このようにして、APIがすべての期待を満たしているかどうかをテストします。

これがCDCの*コンシューマー主導*の部分の由来であることがわかります。コンシューマーは、期待を記述することにより、インターフェースの実装を推進します。プロバイダーは、すべての期待を満たしていることを確認する必要があり、完了です。金メッキ、YAGNI、その他のものはありません。

提供チームにpactファイルを取得するには、複数の方法があります。簡単な方法は、バージョン管理にチェックインし、提供チームに常にpactファイルの最新バージョンをフェッチするように指示することです。より高度な方法は、アーティファクトリポジトリ、AmazonのS3やpactブローカーなどのサービスを使用することです。シンプルに始めて、必要に応じて成長させてください。

実際のアプリケーションでは、クライアントクラスに対して*統合テスト*と*コンシューマーテスト*の両方は必要ありません。サンプルコードベースには、どちらを使用する方法を示すために両方が含まれています。pactを使用してCDCテストを作成する場合は、後者を使用することをお勧めします。テストの作成に必要な労力は同じです。pactを使用する利点は、他のチームがプロバイダーテストを簡単に実装するために使用できるコントラクトに対する期待を含むpactファイルを自動的に取得できることです。もちろん、これは他のチームにもpactの使用を納得させられる場合にのみ意味があります。これがうまくいかない場合は、*統合テスト*とWiremockの組み合わせが妥当な代替案です。

プロバイダーテスト（他チーム）

プロバイダーテストは、気象APIを提供する担当者が実装する必要があります。私たちは、darksky.netによって提供されるパブリックAPIを使用しています。理論的には、darkskyチームは、アプリケーションとサービス間の契約に違反していないことを確認するために、プロバイダーテストを独自に実装します。

明らかに、彼らは私たちの貧弱なサンプルアプリケーションに関心がなく、私たちのためにCDCテストを実装することはありません。これは、公開APIとマイクロサービスを採用する組織との大きな違いです。公開APIは、そこにいるすべてのコンシューマーを考慮することはできません。そうしないと、前進できなくなります。組織内では、そうすることができますし、そうすべきです。あなたのアプリは、おそらく少数の、おそらく最大で数十のコンシューマーにサービスを提供するでしょう。安定したシステムを維持するために、これらのインターフェースのプロバイダーテストを作成しても問題ありません。

提供チームは、pactファイルを取得し、提供サービスに対して実行します。そのためには、pactファイルを読み取り、テストデータをスタブアウトし、pactファイルで定義された期待をサービスに対して実行するプロバイダーテストを実装します。

pactの作成者は、プロバイダーテストを実装するためのライブラリをいくつか作成しています。彼らのメインのGitHubリポジトリは、どのコンシューマーとどのプロバイダーライブラリが利用可能かについての優れた概要を提供しています。あなたの技術スタックに最も合うものを選んでください。

簡単にするために、darksky APIもSpring Bootで実装されていると仮定しましょう。この場合、彼らはSpringのMockMVCメカニズムとうまく連携するSpring pactプロバイダーを使用できます。darksky.netチームが実装するであろう仮説的なプロバイダーテストは次のようになります。

@RunWith(RestPactRunner.class)
@Provider("weather_provider") // same as the "provider_name" in our clientConsumerTest
@PactFolder("target/pacts") // tells pact where to load the pact files from
public class WeatherProviderTest {
    @InjectMocks
    private ForecastController forecastController = new ForecastController();

    @Mock
    private ForecastService forecastService;

    @TestTarget
    public final MockMvcTarget target = new MockMvcTarget();

    @Before
    public void before() {
        initMocks(this);
        target.setControllers(forecastController);
    }

    @State("weather forecast data") // same as the "given()" in our clientConsumerTest
    public void weatherForecastData() {
        when(forecastService.fetchForecastFor(any(String.class), any(String.class)))
                .thenReturn(weatherForecast("Rain"));
    }
}

プロバイダーテストが行う必要があるのは、pactファイルを読み込むこと（たとえば、以前にダウンロードしたpactファイルを読み込むために `@PactFolder` アノテーションを使用する）と、事前定義された状態のテストデータをどのように提供するかを定義すること（たとえば、Mockitoモックを使用する）だけです。実装するカスタムテストはありません。これらはすべてpactファイルから派生しています。プロバイダーテストには、コンシューマーテストで宣言された*プロバイダー名*と*状態*に対応するものが存在することが重要です。

プロバイダーテスト（自チーム）

サービスと気象プロバイダー間の契約をテストする方法を見てきました。このインターフェースでは、サービスはコンシューマーとして機能し、気象サービスはプロバイダーとして機能します。もう少し考えてみると、私たちのサービスも他のサービスのプロバイダーとして機能していることがわかります。私たちは、他のサービスが利用できるエンドポイントをいくつか提供するREST APIを提供しています。

契約テストが流行していることを知ったので、もちろんこの契約の契約テストも作成します。幸いなことに、コンシューマー主導の契約を使用しているので、すべてのコンシューマーチームがREST APIのプロバイダーテストを実装するために使用できるPactを送信してくれます。

まず、Spring用のPactプロバイダーライブラリをプロジェクトに追加しましょう。

testCompile('au.com.dius:pact-jvm-provider-spring_2.12:3.5.5')

プロバイダーテストの実装は、前述のパターンと同じです。簡単にするために、単純なコンシューマーからのpactファイルをサービスのリポジトリにチェックインしました。これは、私たちの目的を容易にします。実際のシナリオでは、おそらくpactファイルを配布するためのより洗練されたメカニズムを使用するでしょう。

@RunWith(RestPactRunner.class)
@Provider("person_provider")// same as in the "provider_name" part in our pact file
@PactFolder("target/pacts") // tells pact where to load the pact files from
public class ExampleProviderTest {

    @Mock
    private PersonRepository personRepository;

    @Mock
    private WeatherClient weatherClient;

    private ExampleController exampleController;

    @TestTarget
    public final MockMvcTarget target = new MockMvcTarget();

    @Before
    public void before() {
        initMocks(this);
        exampleController = new ExampleController(personRepository, weatherClient);
        target.setControllers(exampleController);
    }

    @State("person data") // same as the "given()" part in our consumer test
    public void personData() {
        Person peterPan = new Person("Peter", "Pan");
        when(personRepository.findByLastName("Pan")).thenReturn(Optional.of
                (peterPan));
    }
}

示されている `ExampleProviderTest` は、提供されたpactファイルに従って状態を提供する必要があります。それだけです。プロバイダーテストを実行すると、Pactはpactファイルを取得し、サービスに対してHTTPリクエストを送信します。サービスは、設定した状態に従って応答します。

ユーザーインターフェースエンドツーエンドテスト

エンドツーエンドテストでは、Selenium と WebDriver プロトコルが多くの開発者にとって最適なツールです。Seleniumを使用すると、好きなブラウザを選択し、自動的にWebサイトを呼び出し、あちこちをクリックし、データを入力し、ユーザーインターフェイスで内容が変更されていることを確認できます。

Seleniumは、テストの実行に起動して使用できるブラウザが必要です。使用できるさまざまなブラウザ用のいわゆる「ドライバー」が複数あります。1つ（または複数）を選択し、build.gradleに追加します。どのブラウザを選択しても、チームのすべての開発者とCIサーバーが正しいバージョンのブラウザをローカルにインストールしていることを確認する必要があります。これを同期させるのは非常に面倒な場合があります。Javaの場合、webdrivermanager という便利な小さなライブラリがあり、使用するブラウザの正しいバージョンのダウンロードと設定を自動化できます。これらの2つの依存関係をbuild.gradleに追加すれば、準備完了です。

testCompile('org.seleniumhq.selenium:selenium-chrome-driver:2.53.1')
testCompile('io.github.bonigarcia:webdrivermanager:1.7.2')

テストスイートで本格的なブラウザを実行するのは面倒な場合があります。特に継続的デリバリーを使用する場合、パイプラインを実行しているサーバーは、ユーザーインターフェイスを含むブラウザを起動できない場合があります（たとえば、Xサーバーがないため）。xvfbのような仮想Xサーバーを起動することで、この問題の回避策をとることができます。

より最近のアプローチは、ヘッドレスブラウザ（つまり、ユーザーインターフェイスのないブラウザ）を使用してwebdriverテストを実行することです。最近まで、PhantomJS はブラウザの自動化に使用される主要なヘッドレスブラウザでした。Chromium と Firefox の両方がブラウザにヘッドレスモードを実装したことを発表して以来、PhantomJSは突然時代遅れになりました。結局のところ、開発者にとって便利だからという理由だけで人工的なブラウザを使用するのではなく、ユーザーが実際に使用しているブラウザ（FirefoxやChromeなど）でWebサイトをテストする方が良いでしょう。

ヘッドレスFirefoxとChromeはどちらもまったく新しく、webdriverテストの実装にはまだ広く採用されていません。ここでは物事をシンプルに保ちたいと思います。最先端のヘッドレスモードを使用しようと苦労するのではなく、Seleniumと通常のブラウザを使用した従来の方法に固執しましょう。Chromeを起動し、サービスに移動して、Webサイトのコンテンツを確認する簡単なエンドツーエンドテストは次のようになります。

@RunWith(SpringRunner.class)
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
public class HelloE2ESeleniumTest {

    private WebDriver driver;

    @LocalServerPort
    private int port;

    @BeforeClass
    public static void setUpClass() throws Exception {
        ChromeDriverManager.getInstance().setup();
    }

    @Before
    public void setUp() throws Exception {
        driver = new ChromeDriver();
    }

    @After
    public void tearDown() {
        driver.close();
    }

    @Test
    public void helloPageHasTextHelloWorld() {
        driver.get(String.format("http://127.0.0.1:%s/hello", port));

        assertThat(driver.findElement(By.tagName("body")).getText(), containsString("Hello World!"));
    }
}

このテストは、このテストを実行するシステム（ローカルマシン、CIサーバー）にChromeがインストールされている場合にのみシステムで実行されることに注意してください。

テストは簡単です。@SpringBootTestを使用して、ランダムなポートでSpringアプリケーション全体を起動します。次に、新しいChrome webdriverをインスタンス化し、マイクロサービスの/helloエンドポイントに移動して、ブラウザウィンドウに「Hello World！」と表示されることを確認します。素晴らしい！Webインターフェースを使用していない場合でも、エンドツーエンドテストとしては十分すぎるほどです。

REST APIエンドツーエンドテスト

アプリケーションをテストする際にグラフィカルユーザーインターフェイスを回避することは、アプリケーションスタックの広い部分をカバーしながら、完全なエンドツーエンドテストよりも不安定性の低いテストを作成するための良いアイデアになる可能性があります。これは、アプリケーションのWebインターフェイスを介したテストが特に難しい場合に役立ちます。Web UIがなくてもREST APIを提供している場合（シングルページアプリケーションがそのAPIと通信しているため、または単に素晴らしいものがすべて嫌いなため）、グラフィカルユーザーインターフェイスのすぐ下をテストし、自信を損なうことなく非常に遠くまで到達できる皮下テストが役立ちます。私たちのサンプルコードのようにREST APIを提供している場合に最適です。

@RestController
public class ExampleController {
    private final PersonRepository personRepository;

    // shortened for clarity

    @GetMapping("/hello/{lastName}")
    public String hello(@PathVariable final String lastName) {
        Optional<Person> foundPerson = personRepository.findByLastName(lastName);

        return foundPerson
             .map(person -> String.format("Hello %s %s!",
                     person.getFirstName(),
                     person.getLastName()))
             .orElse(String.format("Who is this '%s' you're talking about?",
                     lastName));
    }
}

REST APIを提供するサービスをテストする際に役立つライブラリをもう1つご紹介します。REST-assured は、APIに対して実際のHTTPリクエストを発行し、受信したレスポンスを評価するための優れたDSLを提供するライブラリです。

まず最初に、依存関係をbuild.gradleに追加します。

testCompile('io.rest-assured:rest-assured:3.0.3')

このライブラリを使用すると、REST APIのエンドツーエンドテストを実装できます。

@RunWith(SpringRunner.class)
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
public class HelloE2ERestTest {

    @Autowired
    private PersonRepository personRepository;

    @LocalServerPort
    private int port;

    @After
    public void tearDown() throws Exception {
        personRepository.deleteAll();
    }

    @Test
    public void shouldReturnGreeting() throws Exception {
        Person peter = new Person("Peter", "Pan");
        personRepository.save(peter);

        when()
                .get(String.format("http://localhost:%s/hello/Pan", port))
        .then()
                .statusCode(is(200))
                .body(containsString("Hello Peter Pan!"));
    }
}

ここでも、@SpringBootTestを使用してSpringアプリケーション全体を起動します。この場合、PersonRepositoryを@Autowireして、テストデータをデータベースに簡単に書き込めるようにします。REST APIに「Mr Pan」への挨拶を依頼すると、素敵な挨拶が表示されます。素晴らしい！Webインターフェースを使用していない場合でも、エンドツーエンドテストとしては十分すぎるほどです。