著者について： Ham Fokkeは、ドイツのThoughtWorks開発者およびコンサルタントです。 3晩の展開にうんざりしていた彼は、ツールキットに継続的な配信と徹底した自動化の手段を追加しました。 現在、他のチーム向けにこのようなシステムをセットアップして、信頼性の高い効率的なソフトウェア配信を確保しています。 そこで彼は、これらの迷惑な小さな人々が彼らのふざけた行動に費やす時間を企業に節約します。

テストピラミッドは、さまざまな詳細レベルでソフトウェアテストをグループ化することを意味するメタファーです。 また、これらの各グループにいくつのテストを行うべきかというアイデアも提供します。 テストピラミッドの概念は長い間存在していたという事実にもかかわらず、多くの開発チームは、それを正しく正しく実行しようとしています。 この記事では、テストピラミッドの初期概念について説明し、それを実現する方法を示します。 ピラミッドのさまざまなレベルでどのタイプのテストを検索する必要があるかを示し、それらの実装方法の実用的な例を示します。

ソフトウェアはリリース前にテストする必要があります。 ソフトウェア業界が成熟するにつれて、テスト手法が成熟しました。 無数の生きたテスターの代わりに、開発者はほとんどのテストの自動化に切り替えました。 テストの自動化により、数日または数週間後にではなく、コードに入力されてから数秒および数分でバグを見つけることができます。

自動テストによって強化された劇的に短縮されたフィードバックループは、アジャイル開発プラクティス、継続的デリバリー、DevOpsカルチャーと密接に関連しています。 効果的なテストアプローチにより、迅速かつ確実な開発が可能になります。

この記事では、マイクロサービスアーキテクチャ、モバイルアプリケーション、またはIoTエコシステムを構築しているかどうかに関係なく、柔軟性、信頼性、およびサポートを実現するための整形式テストスイートの外観について説明します。 また、効果的で読みやすい自動テストの作成についても詳しく見ていきます。

自動化の重要性（テスト）

ソフトウェアは、私たちが住んでいる世界の不可欠な部分となっています。 ビジネスの効率性を高めるという本来の唯一の目的を超えました。 今日、すべての企業は一流のデジタル企業になることを目指しています。 私たちは毎日、ますます多くのソフトウェアのユーザーとして行動しています。 イノベーションの速度は増加しています。

時代に遅れないようにするには、ソフトウェアの品質を犠牲にすることなく、より迅速にソフトウェアを提供する方法を探す必要があります。 継続的な配信はこれに役立ちます。これは、ソフトウェアがいつでも本番環境にリリースされることを自動的に保証するプラクティスです。 継続的な配信では、アセンブリパイプラインを使用してソフトウェアを自動的にテストし、テスト環境および運用環境に展開します。

すぐに、増え続けるソフトウェアを手動でアセンブル、テスト、展開することは不可能になります-動作中のソフトウェアを提供するのではなく、日常的なタスクを手動で行う場合を除きます。 唯一の方法は、アセンブリからテスト、展開、インフラストラクチャに至るまですべてを自動化することです。



図 1.自動で信頼性の高いソフトウェアの試運転にアセンブリパイプラインを使用する

従来、テストでは、テスト環境での展開を通じて過度の手動作業が必要でした。その後、たとえば、ユーザーインターフェイスの任意の場所をクリックしてバグが表示されるかどうかを確認するブラックボックススタイルのテストが必要でした。 多くの場合、これらのテストはテストスクリプトによって設定され、テスターがすべてを順番にテストするようにします。

明らかに、すべての変更を手動でテストするには多くの時間がかかり、単調で退屈です。 単調さは退屈であり、退屈は間違いにつながります。

幸いなことに、同じタスクのための優れたツールがあります ： オートメーション 。

統一されたテストを自動化すると、開発者としての生活が変わります。 テストを自動化すれば、プログラムの正しい動作を確認するために、クリックプロトコルを無意識にたどる必要がなくなります。 テストを自動化し、目を変えずにコードベースを変更します。 適切なテストセットを使用せずに大規模なリファクタリングを試みたことがあれば、これがどのような恐怖につながるかを知っているはずです。 誤ってプロセスを間違えた場合、どのようにしてわかりますか？ さて、すべてのテストケースを手動でクリックする必要があります。 しかし、正直に言ってみましょう。本当に好きですか？ 大規模な変更を行った後でも、コーヒーを飲みながら数秒以内にバグが現れますか？ 私の意見では、これははるかに優れています。

テストピラミッド

自動化されたテストを真剣に考えている場合、重要な概念が1つあります。 テストピラミッドです。 彼女はMike Cohnの著書Scrum： Agile Software Development Using Scrumで紹介されました。 これは優れた視覚的隠phorであり、さまざまなレベルのテストを示唆しています。 また、各レベルでのテストの量も示します。


図 2.ピラミッドをテストする

マイクコーンの元のテストピラミッドは、3つのレベル（下から上）で構成されています。

1. 単体テスト。
2. サービステスト
3. ユーザーインターフェイステスト

残念ながら、より徹底的なコンセプトでは不十分のようです。 マイクコーンのテストのピラミッドの命名または概念的な側面のいずれかが完全ではないと主張する人もいますが、私は同意する必要があります。 現代の観点から、テストピラミッドは過度に単純化されているように見えるため、誤解を招く可能性があります。

ただし、シンプルなため、テストピラミッドの本質は、独自のテストスイートを作成する際の経験則です。 このピラミッドから覚えておくべき主なことは、2つの原則です。

1. 異なる詳細のテストを作成します。
2. レベルが高いほど、テストは少なくなります。

ピラミッドの形状に固執して、健康的で高速で保守可能なテストスイートを作成します。 小さくて素早い単体テストを たくさん書いてください。 より一般的なテストをいくつか作成し、アプリケーションを最初から最後までテストする高レベルのエンドツーエンドテストをいくつか作成します。 テストアイスクリームコーンになっていないことを確認してください。これはサポートの悪夢になり、完了するのに時間がかかりすぎます。

テストピラミッドの個々のレベルの名前にあまり執着しないでください。 実際、誤解を招く可能性があります。「サービステスト」という用語は理解するのが難しいです（Cohn自身は、 多くの開発者がこのレベルを完全に無視していることに注意しました）。 最近、React、Angular、Ember.jsなどの単一ページアプリケーションのフレームワークでは、UIテストがピラミッドの最上位に属さないことが明らかになりました。これらすべてのフレームワークでUIを完全にテストできます。

ピラミッドの元の名前の欠点を考えると、テストレベルの他の名前を思い付くのはごく普通のことです。 主なものは、彼らがあなたのチームによって採用されたあなたのコードと用語に対応するということです。

検討するツールとライブラリ

• JUnit ：テストを実行する
• Mockito ：シミュレーションの依存関係
• Wiremock ：スタブ外部サービス用
• 協定 ：CDCテストを書くために
• Selenium ：エンドツーエンドのUIテストを書くため
• REST保証 ：エンドツーエンドREST APIテストを作成するため

応用例

ピラミッドのさまざまなレベルのテストを使用して、 簡単なマイクロサービスを作成しました。

これは典型的なマイクロサービスの例です。 RESTインターフェースを提供し、データベースと通信し、サードパーティのRESTサービスから情報を抽出します。 Spring Bootで実装されており、 Spring Bootを使用したことがない場合でも理解する必要があります。

必ずGithubでコードを確認してください。 readmeファイルには、コンピューターでアプリケーションと自動テストを実行するための指示が含まれています。

機能性

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

GET /hello
"Hello World" . .

GET /hello /{lastname}
. , "Hello {Firstname} {Lastname}" .

GET /weather
, .

高レベルの構造

大まかに言うと、システムの構造は次のとおりです。


図 3.高レベルのマイクロサービス構造

当社のマイクロサービスは、HTTP経由のRESTインターフェースを提供します。 一部のエンドポイントでは、サービスはデータベースから情報を受け取ります。 それ以外の場合、HTTP経由で外部APIにアクセスして、現在の天気を受信して​​表示します。

インテリア建築

内部では、Spring ServiceにはSpringの典型的なアーキテクチャがあります。


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

• Controllerクラスは、 RESTエンドポイントを提供し、 HTTP要求と応答を処理します 。
• Repositoryクラスはデータベースと対話し、永続ストレージとの間でデータを読み書きします。
• Clientクラスは他のAPIとやり取りします。この例では、darksky.netの天気APIからHTTPS経由でJSONデータを取得します 。
• Domainクラスは、ドメインロジックを含むドメインモデルをキャプチャします （正直なところ、これは非常に簡単です）。

経験豊富なSpring開発者は、頻繁に使用されるレイヤーが欠落していることに気付く場合があります。 問題指向の設計に触発された多くの開発者は、 サービスクラスで構成されるサービスレイヤーを作成します。 アプリケーションには含めないことにしました。 その理由の1つは、アプリケーションが非常に単純であり、サービス層が不要なレベルの間接化になることです。 別の理由は、私の意見では、人々はしばしばこれらのレイヤーでそれをやりすぎることです。 多くの場合、サービスクラスがビジネスロジック全体をカバーするコードベースを確認する必要があります。 ドメインモデルはデータの単なるレイヤーになり、動作のレイヤーではありません（ 貧血ドメインモデル ）。 すべての重要なアプリケーションで、優れたコード構造化とテスト容易性のための大きな機会が失われ、オブジェクト指向の力が十分に活用されていません。

リポジトリはシンプルで、シンプルなCRUD機能を提供します。 コードを簡単にするために、 Spring Dataを使用しました。 CRUDリポジトリのシンプルで普遍的な実装を提供します。また、本番環境のように実際のPostgreSQLを使用するのではなく、メモリにテスト用のデータベースをデプロイするように注意します。

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

単体テスト

テストスイートの基礎は、単体テスト（単体テスト）で構成されています。 彼らは、コードベースの別のユニット（ テスト対象 ）が適切に機能していることを検証します。 単体テストには、テストスイート内のすべてのテストの中で最も狭い領域があります。 セット内の単体テストの数は、他のテストの数を大幅に超えています。


図 5.通常、ユニットテストは外部ユーザーをテストテイクに置き換えます。

ユニットとは何ですか？

ユニットテストのコンテキストで「ユニット」が何を意味するかを3人に尋ねると、おそらく4つの異なるわずかに異なる答えが得られます。 ある程度まで、それはあなた自身の定義の問題です-そして、一般に受け入れられた標準的な答えがないことは普通です。

関数型言語で記述する場合、ユニットは別の関数になります。 単体テストは、さまざまなパラメーターを使用して関数を呼び出し、期待される値を返します。 オブジェクト指向言語では、ユニットは単一のメソッドからクラス全体までさまざまです。

社交的で孤独なテスト

被験者のすべての参加者（たとえば、クラスと呼ばれる）をモックまたはスタブに置き換えて、完全な分離を作成し、副作用や複雑なテスト設定を回避する必要があると主張する人もいます。 他の人は、テストを遅くしたり、強い副作用（データベースやネットワーク呼び出しにアクセスできるクラスなど）を示した参加者のみをシミュレーションとスタブに置き換える必要があると主張しています。

これらの2種類の単体テストは、模倣やスタブを完全に使用する場合は単独と呼ばれることもあり 、他の参加者との実際のコミュニケーションの場合は社交的と呼ばれることもあります（これらの用語は、本「効果的な作業」 時間があれば、ウサギの穴を下って、さまざまな視点の長所と短所を理解できます。

ただし、最終的には、どのタイプのテストを選択してもかまいません。 本当に重要なのは、自動化です。 個人的に、私は常に両方のアプローチを使用します。 実際の参加者と作業するのが不便な場合は、シミュレーションとスタブを豊富に使用します。 実際の参加者を引き付けることでテストに自信が持てると感じたら、サービスの最も遠い部分だけをかき消します。

模倣とスタブ

模造品（モック）とスタブ（スタブ）は、2つの異なるタイプのテストダブル （一般的にはもっと多くあります）です。 多くの用語は同じ意味で使用されます。 精度を維持し、それぞれの特定の特性を念頭に置いた方が良いと思います。 実動のオブジェクトに対して、テストダブルはテストの実装を作成します。

簡単に言えば、あなたは本物（クラス、モジュール、関数など）を偽のコピーに置き換えています。 偽物は元のように見え、同じように動作します（同じメソッド呼び出しに同じ答えを与えます）が、これらはユニットテスト用に自分で定義した定義済みの答えです。

テストダブルはユニットテストだけでなく使用されます。 より洗練されたダブルを使用して、システム全体を制御してシミュレートします。 ただし、ユニットテストでは、現代の多くの言語とライブラリを使用すると簡単に作成できるため、特に多くの模倣とスタブ（社交的テストと単一テストのどちらを好むかによって異なります）を使用します。

選択したテクノロジーに関係なく、言語の標準ライブラリまたは一般的なサードパーティライブラリには、シミュレーションを構成するための洗練された方法が既にあります。 また、独自のシミュレーションを最初から作成する場合でも、実際の署名と同じシグネチャとテスト用のシミュレーション設定を使用して、偽のクラス/モジュール/関数を作成するだけです。

ユニットテストは非常に高速に動作します。 まともなマシンでは、数分で数千の単体テストを実行できます。 コードベースの分離された小さなフラグメントを分離してテストし、データベース、ファイルシステム、HTTPリクエストとの接触を回避して（ここでシミュレーションとスタブを設定することにより）高速を維持します。

基本を理解したら、時間の経過とともにユニットテストをより自由かつ簡単に記述できるようになります。 外部参加者をスタブし、入力を構成し、テストサブジェクトを呼び出し、戻り値が期待どおりであることを確認します。 テストによる開発 （TDD）を見て、ユニットテストで開発をガイドします。 それらが正しく適用されると、強力なストリームに入り、適切なサポートアーキテクチャを作成し、包括的で完全に自動化されたテストスイートを自動的に発行するのに役立ちます。 しかし、これは普遍的な解決策ではありません。 試してみて、TDDが適切かどうかを自分で確認してください。

何をテストしますか？

ユニットテストは、機能や所属する内部構造のレベルに関係なく、プロダクションコードのすべてのクラスに対して記述できると便利です。 ユニットテストは、コントローラー、リポジトリ、ドメインクラス、またはファイルリーダーに適しています。 プロダクションクラスごとに1つのテストクラスの実用的なルールに従うだけです。

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

単体テストの作成に関しては、微妙な機能があります。デフォルトのスクリプトや境界線の状況を含め、すべての重要なコードパスがチェックされるようにする必要があります。 同時に、実装と密接に結び付けられるべきではありません。

なぜそう

実動コードに添付されすぎているテストはすぐにいらいらし始めます。 コードをリファクタリングすると（つまり、外部の動作を変更せずにコードの内部構造を変更すると）すぐに、単体テストはすぐに中断します。

したがって、単体テストの重要な利点を失います：コード変更のセキュリティシステムとして機能します。 これらの馬鹿げたテストはすぐに疲れてしまい、リファクタリング後に毎回落ちるので、良い問題よりも多くの問題が発生します。 テストを実装するこの愚かなアイデアは誰のアイデアですか？

どうする？ コードの内部構造を単体テストに反映しないでください。 観察された動作をテストします。 例：

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

代わりに：

xとyを導入する場合、メソッドは最初にクラスAになり、次にクラスBになり、次にクラスAとクラスBからの結果を追加しますか？

原則として、プライベートメソッドは実装の一部として検討する必要があります。 それが、それらをテストしたいという願望さえもあるべきではない理由です。

多くの場合、ユニットテスト（またはTDD）の反対者から、大規模なテストカバレッジのためにすべてのメソッドをテストする必要がある場合、ユニットテストの作成は無意味になると聞きます。 多くの場合、100％のテストカバレッジに到達するために、過度に短気なチームリーダーがゲッター、セッター、およびその他の簡単なコードのユニットテストを強制的に作成するシナリオを参照します。

これは完全に間違っています。

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

しかし、私は本当にこのプライベートメソッドをチェックする必要があります
閉じたメソッドを本当に、本当にチェックする必要がある状況に自分自身を見つけた場合、一歩後退して自分に尋ねる必要があります：なぜですか？

ここが設計上の問題である可能性が高いと確信しています。 最も可能性が高いのは、プライベートメソッドをテストする必要があると感じることです。プライベートメソッドは複雑であり、クラスのオープンインターフェイスを介してメソッドをテストするには、あまりにも不便な設定が必要だからです。

このような状況に陥ったときはいつでも、通常、テストされたクラスは複雑すぎるという結論に達します。 彼はやり過ぎであり、責任の共有という原則に違反しています。

私にとっては、ソースクラスを2つのクラスに分割するソリューションがよく機能します。 多くの場合、1〜2分考えた後、大きなクラスを個々の責任で2つの小さなクラスに分割する良い方法があります。 プライベートメソッド（緊急にテストする必要がある）を新しいクラスに移動し、古いクラスに新しいメソッドを呼び出させます。 テストには不便なプライベートメソッドであるVoilaは、現在公開されており、テストが容易です。 さらに、単一責任の原則を導入することにより、コード構造を改善しました。

試験構造

すべてのテスト（ユニットテストだけでなく）の適切な構造は次のとおりです。

1. テストデータのセットアップ。
2. テストメソッドを呼び出します。
3. 期待される結果が返されることを確認してください。

この構造を記憶するための良いニーモニックがあります：3 A（ Arrange、Act、Assert ）。 BDDでルートを持つ他のニーモニックを使用できます（動作の説明に基づいた開発）。 このトライアドは、「与えられた」が設定を反映し、「いつ」がメソッド呼び出しであり、「その後」がステートメントである場合に与えられます。

このパターンは、他のより高いレベルのテストに適用できます。 いずれの場合も、テストが簡単で読みやすくなるようにします。 さらに、この構造を念頭に置いて記述されたテストは、通常、より短く、より表現力豊かです。

単体テストの実装

これで、テストする対象と単体テストを構成する方法がわかりました。 現実の例を見てみましょう。

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クラスをテスト用のスタブを持つクラスに置き換えます。 このスタブを使用すると、スタブメソッドが返す定義済みの回答を指定できます。 このアプローチにより、テストがより簡単で予測しやすくなり、データ検証の設定が簡単になります。

「スリーA」の構造に従って、希望する人が見つからない場合のポジティブおよびネガティブケースについて2つのユニットテストを作成します。 ポジティブテストケースは、新しいpersonオブジェクトを作成し、 lastNameパラメーターがPanの値で呼び出されたときにこのオブジェクトを返すようにリポジトリシミュレーションに指示します。 次に、テストはテストメソッドを呼び出します。 最後に、彼は答えを予想と比較します。

2番目のテストも同様に機能しますが、テストメソッドがこのパラメーターの人物オブジェクトを見つけられないシナリオをテストします。

専門のテストヘルパー
アプリケーションのアーキテクチャレベルに関係なく、コードベース全体の単体テストを作成できることは素晴らしいことです。 以下の例は、コントローラーの単純な単体テストを示しています。 残念ながら、Springコントローラーに関しては、このアプローチには欠点があります。SpringMVCコントローラーは、リスニングパス、使用されるHTTPコマンド、URL解析パラメーター、リクエストパラメーターなどの宣言でアノテーションを集中的に使用します。 単体テストでコントローラメソッドを単純に呼び出しても、これらすべての重要なことはテストされません。 幸いなことに、Springコミュニティは、コントローラーテストの改善に使用できる優れたテストヘルパーを考案しました。 必ずMockMVCをチェックしてください 。 これにより、偽のコントローラー要求を生成し、すべてが正常に機能していることを確認するための優れたDSLが提供されます。 コードに例を含めました 。 多くのフレームワークには、コードの特定の部分のテストを簡素化するテストヘルパーがあります。 フレームワークのドキュメントを調べて、自動テストに役立つヘルパーが提供されているかどうかを確認してください。

統合テスト

重要なアプリケーションはすべて、他の一部（データベース、ファイルシステム、他のアプリケーションへのネットワーク呼び出し）と統合されています。 単体テストでは、通常、より優れた分離と速度のためにそれらをシミュレートします。 ただし、アプリケーションは実際に他の部分とやり取りするため、これをテストする必要があります。 このために、 統合テストが意図されています。 それらは、アプリケーション外部のすべてのコンポーネントとのアプリケーション統合を検証します。

自動テストの場合、これは、独自のアプリケーションだけでなく統合コンポーネントも実行する必要があることを意味します。 データベースとの統合をテストしている場合は、テストを実行するときにデータベースを実行する必要があります。 ディスクからのファイルの読み取りを確認するには、ファイルをディスクに保存し、統合テストにロードする必要があります。

ユニットテストは無期限の用語であると先に述べました。 これは統合テストにさらに適用されます。 一部の場合、「統合」とは、アプリケーションのスタック全体を他のアプリケーションと組み合わせてテストすることを意味します。 私は、各統合ポイントのより狭い定義とテストを個別に好み、残りのサービスとデータベースをテストの研究に置き換えます。 契約テストと、アンダースタディーおよび実際の実装に関する契約テストの実行と合わせて、より速く、より独立した、通常は理解しやすい統合テストを思い付くことができます。

狭い統合テストは、サービスの境界で実行されます。 概念的には、外部パーツ（ファイルシステム、データベース、個別のサービス）との統合につながるアクションを常にトリガーします。 データベース統合テストは次のとおりです。


図 6.データベース統合テストは、コードを実際のデータベースと統合します

1. データベースの実行。
2. アプリケーションをデータベースに接続します。
3. データベースにデータを書き込むコードで関数を実行します。
4. データベースからデータを読み取ることにより、予期されるデータがデータベースに書き込まれることを確認します。

別の例。 REST APIを介してサービスを別のサービスと統合するためのテストは次のようになります。


図 7.このタイプの統合テストでは、アプリケーションが個々のサービスと適切に対話できることを確認します。

1. アプリケーションの起動。
2. 別のサービスのインスタンス（または同じインターフェイスを使用したテストバックアップ）を起動します。
3. 外部サービスAPIからデータを読み取るコードで関数を実行します。
4. アプリケーションが応答を正しく解析することを確認します。

単体テストと同様に、統合テストは非常に透過的に実行できます（ホワイトボックス）。 一部のフレームワークでは、アプリケーションを同時に起動し、個々の部分をシミュレートして正しい相互作用を検証できます。

データがシリアル 化または非シリアル 化されるすべてのコードに対して統合テストを記述します。 これは、思っているよりも頻繁に起こります。 次のことを考えてください：

• サービスへのREST API呼び出し。
• データベースの読み取りと書き込み。
• 他のアプリケーションへのAPI呼び出し。
• キューから読み取り、そこに書き込みます。
• ファイルシステムへの書き込み。

これらの境界の周りに統合テストを記述することにより、これらの外部参加者からのデータの書き込みと読み取りが正常に機能することが保証されます。狭い統合テストを

作成する場合、外部の依存関係をローカルで実行してみてください：ローカルMySQLデータベース、ローカルext4ファイルシステムでのテスト。別のサービスと統合する場合は、このサービスのインスタンスをローカルで開始するか、実際のサービスの動作を模倣する偽バージョンを作成して実行します。

サードパーティのサービスをローカルで開始できない場合は、専用のテストインスタンスを実行し、統合テストでそれをポイントすることをお勧めします。自動テストでは、実際の本番システムとの統合を避けます。本番システムに対して何千ものテストリクエストを実行することは、ログを記録する（せいぜい）か、サービスを提供する（最悪の場合）ため、人々を怒らせる確実な方法です。ネットワーク統合は、広範な統合テストの典型的な機能です。通常、テストは記述が難しく、実行速度が遅くなります。

テストピラミッドに関しては、統合テストは単体テストよりも高いレベルにあります。ファイルシステムとデータベースの統合は、通常、シミュレーションを使用した単体テストの実行よりもはるかに遅くなります。また、小さな単体テストよりも記述が困難です。最後に、テストの外部部分の作業について考える必要があります。それにも関わらず、それらは必要なすべての外部部品でアプリケーションの正しい動作に自信を与えるため、利点があります。単体テストはここでは役に立ちません。

DB統合

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

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

インタフェースを介してCrudRepositoryスプリングブーツは完全に機能するリポジトリCRUDメソッドを提供するfindOne、findAll、save、updateおよびdelete。メソッドの独自の定義は、findByLastName ()この基本的な機能を拡張し、人、つまりオブジェクトをPerson姓で受け取ることを可能にします。 Spring Dataはメソッドの戻り値の型、メソッドの名前を解析し、命名規則に準拠しているかどうかをチェックして、何をすべきかを判断します。

Spring Dataはデータベースリポジトリを実装する上で素晴らしい仕事をしていますが、私はまだデータベース統合テストを書きました。これはフレームワークテストであると言えます。、他の人のコードをテストしているので、避けるべきです。それでも、ここでは少なくとも1つの統合テストの存在が非常に重要であると考えています。まず、methodの通常の動作をチェックしますfindByLastName。次に、リポジトリがSpringを正しく使用し、データベースに接続できることを証明します。

（PostgreSQLデータベースをインストールせずに）コンピューターでテストを実行しやすくするために、テストはH2メモリのデータベースに接続します。

H2をファイル内のテスト依存関係として定義しましたbuild.gradle。application.propertiesテストディレクトリ内のファイルは、プロパティを定義しませんspring.datasource。これにより、Spring Dataはメモリ内のデータベースを使用するようになります。彼はクラスへの途中でH2を見つけたため、単純にH2を使用します。

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

ここでは、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))); } } 

ご覧のとおり、統合テストは単体テストと同じ「3 A」構造に従います。彼はこれは普遍的な概念だと言った！

個々のサービスとの統合

マイクロサービスは、REST APIを介してdarksky.netから気象データを受け取ります。もちろん、サービスがリクエストを正しく送信し、回答を解析することを確認する必要があります。

自動テストを実行するときは、実際のdarkskyサーバーとの相互作用を避けることをお勧めします。無料レートの制限は、その理由の1つにすぎません。主なものはデカップリングです。 darksky.netの優れた人々が仕事をしても、テストは実行されるはずです。マシンが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の場合WireMockRule、固定ポート（8089）にインスタンスを作成します。 DSLを使用して、Wiremockサーバーを構成し、リッスンするエンドポイントを決定し、応答を事前定義できます。

次に、テストメソッド（サードパーティサービスにアクセスするメソッド）を呼び出し、結果が正しく解析されることを確認します。

実際のdarksky APIの代わりに偽のWiremockサーバーを使用すべきであるとテストが判断する方法を理解することが重要です。秘密のファイルapplication.propertiesに位置していますsrc/test/resources。テストの実行時に、Springがロードします。このファイルでは、テストに適した値を持つAPIキーやURLなどの構成を再定義します。特に、実際のWiremockサーバーではなく、偽のWiremockサーバーに呼び出しを割り当てます。

 weather.url = http://localhost:8089 

ここで定義するポートは、テスト用にWireMockRuleインスタンスを作成するときに指定したものと同じでなければならないことに注意してください。実際のAPIのURLを偽のURLに置き換えるには、URLをクラスコンストラクターに導入しますWeatherClient。

 @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ため、アプリケーションのプロパティで定義したweatherUrlproperty パラメーターの値を読み取るように指示しweather.urlます。

Wiremockのようなツールを使用すると、単一のサービスの狭い統合テストを作成するのは非常に簡単な作業になります。残念ながら、このアプローチには欠点があります。作成した偽のサーバーが実際のサーバーのように動作することを保証する方法はありますか？現在の実装では、別のサービスでAPIを変更できますが、テストは何も起こらなかったようにパスします。現在WeatherClient、偽のサーバーからの応答を受け入れることができるものをテストしています。これは始まりですが、非常に壊れやすいです。エンドツーエンドのテストは問題を解決します。実際のサービスでテストしますが、この方法では可用性に依存します。幸いなことに、このジレンマに対するより良い解決策があります-契約テストとシミュレーション、および実際のサーバーは、統合テストのシミュレーションが元のものと正確に一致することを保証します。仕組みを見てみましょう。

契約テスト

より近代的な企業は、異なるチームに作業を分散させることで開発を拡大する方法を見つけました。相互に干渉することなく、疎結合の個別のサービスを作成し、それらを大規模でシームレスなシステムに統合します。これが、マイクロサービスに関する最近の誇大宣伝のすべてです。

システムを多くの小さなサービスに分割するということは、多くの場合、これらのサービスが特定の（できれば明確に定義されているが、ランダムに作成される）インターフェイスを介して相互にやり取りする必要があることを意味します。

さまざまなアプリケーション間のインターフェイスは、さまざまな形式とテクノロジーで実装できます。最も一般的な：

• HTTPS経由のRESTおよびJSON。
• gRPCのようなものを使用したRPC 。
• キューを使用してイベント駆動型アーキテクチャを構築します。

各インターフェイスには、サプライヤとコンシューマの2つの側面が含まれます。サプライヤーは、消費者にデータを提供します。消費者は、供給者から受け取ったデータを処理します。 RESTの世界では、プロバイダーは必要なすべてのエンドポイントを使用してREST APIを作成し、コンシューマーはこのREST APIを使用してデータを取得したり、別のサービスへの変更を開始したりします。イベント駆動型アーキテクチャの非同期の世界では、プロバイダー（多くの場合、パブリッシャーと呼ばれます）はキュー内のデータをパブリッシュします。コンシューマ（サブスクライバとも呼ばれる）はこれらのキューにサブスクライブし、データを読み取り、処理します。


図 8.各インターフェイスには、サプライヤ（またはパブリッシャー）とコンシューマ（またはサブスクライバー）が含まれます。インターフェイス仕様は契約と見なすことができます。

サプライヤとコンシューマのサービスは異なるチームに従って分散されているため、それらの間のインターフェースを明確に示す必要がある状況にあります（いわゆる契約）。従来、企業はこの問題に次のように取り組んでいます。

1. インターフェースの詳細で詳細な仕様を記述します（コントラクト）。
2. 特定の契約に従ってサプライヤのサービスを実装します。
3. インターフェース仕様をコンシューマー側に転送します。
4. インターフェイスの一部を実装するまで待ちます。
5. 大規模な手動システムテストを実行して、すべてを検証します。
6. 両方のチームが常にインターフェイスの定義を順守し、邪魔されないことが望まれます。

最近の企業では、手順5と6を自動化された契約テストに置き換え、顧客とサプライヤの実装が特定の契約に準拠していることを確認しています。これらは回帰テストの優れたセットであり、契約からの逸脱の早期検出を保証します。

より柔軟な組織は、より効率的で無駄の少ないルートを選択する必要があります。アプリケーションは1つの組織内で作成されます。他のサービスの開発者に過度に詳細なドキュメントを投げるのではなく、開発者と話すことは問題ではないはずです。最終的に、これらは従業員であり、カスタマーサポートまたは防弾の法的契約を通じてのみ通信できるサードパーティベンダーではありません。

ユーザー指向の契約テスト（CDCテスト）により、消費者は契約の実装を管理できます。消費者はCDCを使用して、必要なすべてのデータのインターフェイスをテストするテストを作成します。その後、チームはこれらのテストを公開して、ベンダーサービス開発者がこれらのテストを簡単に取得して実行できるようにします。これで、CDCテストを実行してAPIを開発できます。すべてのテストを実行した後、彼らは消費者側のチームのすべてのニーズを満たしていることを知っています。


図 9.契約テストでは、インターフェイスのサプライヤとすべてのコンシューマが特定のインターフェイス契約に準拠していることを確認します。インターフェイスコンシューマは、CDCテストを使用して、要件を自動テストの形式で公開します。サプライヤーが継続的にこれらのテストを受け、実行

このアプローチは、本当に必要なものだけを実装するためのインタフェースプロバイダチーム（それをシンプルに保つ、ことができます YAGNIをそしてすべて）。ベンダーチームは、重大な変更を即座に通知するために、これらのCDCテストを（アセンブリパイプラインで）継続的に受信して実行する必要があります。インターフェイスに違反すると、CDCテストが失敗し、重大な変更が妨げられます。テストに合格すると、チームは他のチームを心配することなく、必要な変更を加えることができます。顧客志向の契約アプローチにより、開発プロセスは次のように短縮されます。

1. 消費者チームは、消費者からの期待をすべて満たした自動テストを作成します。
2. サプライヤチーム向けにテストを公開します。
3. ベンダーチームは、CDCテストを継続的に実行および監視します。
4. CDCテストが中断すると、チームはすぐに交渉します。

組織でマイクロサービスアプローチを実装している場合、CDCテストを実施することは、自律グループを作成するための重要なステップです。 CDCテストは、チームワークを促進する自動化された方法です。チーム間のインターフェースが常に機能するようにします。失敗したCDCテストは、影響を受けるチームに行き、APIの今後の変更について話し、次にどこに行くべきかを見つける良い理由です。

CDCテストの単純な実装は、APIを要求し、必要なすべての応答を評価するのと同じくらい簡単です。これらのテストは、実行可能ファイル（.gem、.jar、.sh）にパッケージ化され、別のコマンド（たとえば、Artifactoryのようなリポジトリ）のどこかにダウンロードされます。

近年、CDCアプローチがより一般的になり、テストの記述と共有を簡素化するためのいくつかのツールが作成されました。

協定はおそらくそれらの中で最も有名です。コンシューマとサプライヤ向けにテストを記述するための洗練されたアプローチを提供し、個々のサービスにスタブを提供し、CDCテストを他のチームと共有できるようにします。 Pactは多くのプラットフォームに移植されており、JVM、Ruby、.NET、JavaScript、および他の多くの言語で使用できます。

協定は、CDCを始めるための賢明な選択です。ドキュメントは最初は驚異的ですが、忍耐力があれば、それを克服できます。 CDCを確実に理解するのに役立ちます。これにより、他のチームと協力してCDCを促進することが容易になります。

ユーザー指向の契約テストは、迅速かつ自信を持って行動する自律チームの作業を劇的に簡素化できます。お願いします、このコンセプトをチェックしてみてください。優れたCDCテストセットは、他のサービスを中断したり他のチームを混乱させたりすることなく、迅速に開発を継続するために非常に貴重です。

消費者テスト（私たちのチーム）

当社のマイクロサービスは天気APIを使用しています。したがって、私たちの責任は、マイクロサービスと気象サービス間の契約（API）に対する期待を定義する消費者テストを書くことです。

最初に、コンシューマーテストを記述するためのライブラリを組み込みbuild.gradleます。

 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）契約上の期待を特別なJSON形式で記述しています。このファイルを使用して、スタブサーバーが実際のサーバーのように動作することを確認できます。 pactファイルを取得して、それをinterfaceコマンドに渡すことができます。彼らは協定ファイルを取り、そこで指定された期待値を使用してプロバイダーテストを作成します。そのため、彼らは自分たちのAPIがすべての期待を満たしているかどうかを確認します。

ご覧のとおり、CDC定義の「顧客重視」の部分はここから来ています。消費者は、インターフェースの実装を制御し、期待を記述します。サプライヤーは、すべての期待を満たしていることを確認する必要があります。不要な仕様はありません、YAGNIおよびすべてのもの。

ベンダーファイルに協定ファイルを渡すには、いくつかの方法があります。シンプル-バージョン管理システムに登録し、常に最新バージョンのファイルを取得するようベンダーチームに伝えます。より高度な方法は、Amazon S3やPact Brokerなどのアーティファクトリポジトリを使用することです。シンプルに始めて、必要に応じて成長します。

実際のアプリケーションでは、統合テストと消費者テストの両方は必要ありませんクライアントクラス用。サンプルコードには、それぞれの使用方法を示すためだけに両方が含まれています。PactでCDCテストを作成する場合は、そのまま使用することをお勧めします。この場合の利点は、契約の予想が記載された協定ファイルを自動的に受け取ることです。他のチームはこれを使用して、サプライヤーのテストを簡単に行うことができます。もちろん、これは、他のチームにPactを使用するよう説得できる場合にのみ意味があります。そうでない場合は、適切な代替手段としてWiremockとの統合テスト統合を使用します。

サプライヤーテスト（別のチーム）

ベンダーテストは、天気APIを提供する人が実装する必要があります。 darksky.netのパブリックAPIを使用します。理論的には、darkskyチームは、ベンダーテストを実行し、アプリケーションとサービス間の契約に違反しないことを確認する必要があります。

明らかに、彼らは私たちのささやかなテストアプリケーションを気にしません-彼らは私たちのためにCDCテストを行いません。パブリックAPIとマイクロサービスを使用する組織との間には大きな違いがあります。パブリックAPIは、個々の消費者のニーズを考慮することができません。そうしないと、正常に動作できなくなります。組織内では、それらを考慮することができ、考慮する必要があります。ほとんどの場合、アプリケーションはいくつかの、おそらくは数十の消費者にサービスを提供します。安定したシステムを維持するために、これらのインターフェイスのベンダーテストを書くことを妨げるものは何もありません。

サプライヤチームは協定ファイルを受け取り、そのサービスで実行します。これを行うために、彼女は協定ファイルを読み取り、いくつかのスタブを配置し、協定ファイルで定義された期待値をサービスにチェックするテストを実装します。

Pactプロジェクトコミュニティは、ベンダーテストを実装するためのライブラリをいくつか作成しました。彼らのメインリポジトリのGitHubの利用者と提供のためのライブラリの良い選択。技術スタックに最適なものを選択してください。

簡単にするために、darksky APIもSpring Bootに実装されているとします。この場合、彼らはSpringのMockMVCメカニズムにうまく接続するPact Springライブラリを使用できます。 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")); } } 

ご覧のとおり、サプライヤは協定ファイルをダウンロードするだけで（たとえば、@PactFolder受け取った協定ファイルのダウンロード元を決定し）、事前定義された状態のテストデータを提供する方法を決定できます（たとえば、Mockitoシミュレーションを使用）。特別なテストを書く必要はありません。すべてが協定ファイルから取得されます。サプライヤテストは、サプライヤの名前とコンシューマテストで宣言された状態と一致することが重要です。

サプライヤーテスト（私たちのチーム）

サービスと天気情報プロバイダー間の契約をテストする方法を検討しました。このインターフェースでは、当社のサービスは消費者として機能し、気象サービスは供給者として機能します。さらに考えてみると、私たちのサービスは他のサービスのプロバイダーとしても機能することがわかります。他のコンシューマー向けに複数のエンドポイントを備えたREST APIを提供します。

契約テストの重要性を知っているので、もちろんこの契約のテストも作成します。幸いなことに、私たちの契約は顧客志向であるため、すべての消費者チームが私たちに協定ファイルを送信します。これを使用して、REST APIのベンダーテストを実装できます。

最初に、SpringのPactプロバイダーライブラリをプロジェクトに追加します。

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

ベンダーテストの実装は、説明したものと同じパターンに従います。簡単にするために、単純なコンシューマーからの協定ファイルをサービスのリポジトリーに登録します。私たちの場合、これは簡単ですが、実際には、おそらくより複雑なメカニズムを使用して協定ファイルを配布する必要があります。

 @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ファイルを取得し、指定された状態に従って応答するHTTP要求をサービスに送信します。

UIテスト

ほとんどのアプリケーションには、ある種のユーザーインターフェイスがあります。通常、WebアプリケーションのコンテキストでWebインターフェイスについて説明します。 REST APIまたはコマンドラインインターフェースが派手なWebインターフェースと同じUIであることを忘れがちです。

UIテストは、アプリケーションユーザーインターフェイスの正しい動作を検証します。ユーザーアクションは適切なイベントをトリガーし、データはユーザーに提示され、UIの状態は期待どおりに変化する必要があります。



UIテストとエンドツーエンドテストは同じものであると言われることもあります（Mike Cohnが言うように）。私にとって、これは非常に直交する概念を持つ2つのことの識別です。

はい、アプリケーションを最初から最後までテストすることは、多くの場合、ユーザーインターフェイスを使用することを意味します。しかし、その逆は真実ではありません。

ユーザーインターフェイスのテストは、エンドツーエンドである必要はありません。使用されているテクノロジーによっては、UIテストは、ミュートされたバックエンドを備えたJavaScriptフロントエンドの単体テストを作成するのと同じくらい簡単な場合があります。Selenium

などの特別なツールは、従来のWebアプリケーションのUIをテストするために設計されています。。ユーザーインターフェイスがREST APIであると思われる場合は、APIに関する適切な統合テストで十分です。

Webインターフェースでは、動作、レイアウト、使いやすさ、企業IDコンプライアンスなど、UIのいくつかの側面をテストすることが望ましいです。

幸いなことに、UIの動作のテストは非常に簡単です。ここをクリックして、そこにデータを入力し、UIの状態がそれに応じて変化することを確認してください。単一ページアプリケーション用の最新のフレームワーク（react、vue.js、Angularその他）、これらの相互作用をかなり低いレベル（ユニットテスト）で徹底的にテストするためのツールとヘルパーが付属していることがよくあります。独自のフロントエンド実装をバニラJavaScriptで展開した場合でも、JasmineやMochaなどの通常のテストツールを使用できます。より伝統的なサーバーサイドレンダリングアプリケーションの場合、Seleniumベースのテストが最良の選択です。Webアプリケーションレイアウト

の整合性を確認するのはもう少し困難です。アプリケーションとユーザーのニーズによっては、コードの変更が誤ってサイトのレイアウトに違反しないようにする必要があります。

しかし、コンピューターは、すべてが「正常に見える」ことを検証するのに貧弱な仕事をします（おそらく、いくつかのスマート機械学習アルゴリズムは将来それを変更するでしょう）。

アセンブリパイプラインでWebアプリケーションの設計を自動的にチェックしようとするツールがいくつかあります。それらのほとんどはSeleniumを使用して、さまざまなブラウザーと形式でWebアプリケーションを開き、スクリーンショットを撮り、以前のスクリーンショットと比較します。古いスクリーンショットと新しいスクリーンショットが予期せず異なる場合、ツールはシグナルを出します。

そのようなツールの1つがGalenです。一部のチームは、ラインナップと彼の兄弟のJavaベースのjlineupを使用して同様の結果を達成しています。どちらのツールも同じSeleniumベースのアプローチを使用します。

ユーザビリティと優れたデザインをテストしたいとすぐに-自動テストのスペースを離れます。ここでは、研究テスト、ユーザビリティテスト（ランダムな人に対する最も単純なホールテストまで）に依存する必要があります。ユーザーはデモンストレーションを行い、製品が好きかどうか、フラストレーションや迷惑なくすべての機能を使用できるかどうかを確認する必要があります。

エンドツーエンドのテスト

UIを介したデプロイ済みアプリケーションのテストは、実行可能な最も包括的なテストです。WebDriverを介した上記のUIテストは、エンドツーエンドテストの良い例です。


図 11.統合システム全体をテストする

エンドツーエンドテスト：エンドツーエンドテスト（ワイドスタックテストとも呼ばれます）は、ソフトウェアが機能するかどうかを最大限に保証します。 Seleniumと WebDriverプロトコルを使用すると、ヘッドレスブラウザーをデプロイ済みサービスに自動的に送信してクリックを実行し、データを入力し、UIのステータスを確認することで、テストを自動化できます。 Seleniumを直接使用するか、Seleniumに基づいた Nightwatchなどのツールを使用できます。

エンドツーエンドのテストには他の問題があります。それらは、その不安定さ、予期せぬ予期しない理由による失敗で知られています。多くの場合、これらは誤検知の失敗です。 UIが複雑になるほど、テストは脆弱になります。ブラウザの癖、タイミングの問題、アニメーション、予期しないポップアップは、私が思っていたよりもデバッグに多くの時間を費やした理由のほんの一部です。

マイクロサービスの世界では、誰がこれらのテストを書く責任があるのか​​も不明です。それらはいくつかのサービス（システム全体）を対象としているため、エンドツーエンドのテストを作成する特定のチームはありません。

一元化された品質保証チームがある場合彼らは良い候補のように見えます。繰り返しますが、一元化されたQAチームを開始することは厳密には推奨されません。これは、すべてのチームが真に普遍的なDevOpsの世界ではありません。誰がエンドツーエンドのテストを所有する必要があるかについての簡単な答えはありません。あなたの組織には、それらを管理するための何らかのイニシアチブグループまたは質の高いギルドがあるかもしれません。多くは特定の組織に依存します。

さらに、エンドツーエンドのテストには深刻なサポートが必要であり、かなり遅いです。多くのマイクロサービスがある場合、すべてのマイクロサービスをローカルで実行する必要があるため、エンドツーエンドのテストをローカルで実行することさえできません。コンピューターで何百ものアプリケーションを実行してみてください。十分なRAMがありません。

メンテナンスコストが高いため、エンドツーエンドテストの数は最小限に抑える必要があります。

アプリケーションとの最も重要なユーザーインタラクションについて考えます。エンドツーエンドのテストでこれらの手順の最も重要な手順を自動化するために、画面から画面へのユーザーの主な「ルート」を考えてください。

あなたがオンラインストアをしている場合、最も価値のある「ルート」は製品を検索することです-バスケットに入れて-注文します。以上です。このルートが機能する限り、特に問題はありません。エンドツーエンドのテストのために、さらに重要なルートがいくつか見つかるかもしれません。他のすべては、良いよりも多くの問題をもたらす可能性があります。

覚えておいてください。テストピラミッドには多くの低レベルのテストがあり、境界状況やシステムの他の部分との統合に関するすべてのオプションを既にテストしています。これらのテストをより高いレベルで繰り返す必要はありません。多大な保守作業と多くの誤検知により、作業が非常に遅くなり、遅かれ早かれ、テストに対する自信がまったく失われます。

エンドツーエンドUIテスト

エンドツーエンドのテストでは、多くの開発者がSeleniumとWebDriverプロトコルを選択します。 Seleniumを使用すると、任意のブラウザーを選択してサイトに設定できます。どこでもボタンとリンクを押して、データを入力し、UIで変更を確認します。

Seleniumには、実行してテストに使用できるブラウザーが必要です。さまざまなブラウザー用のいわゆる「ドライバー」がいくつかあります。 1つ（または複数）を選択して、それをyoursに追加します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') 

テストスイートでフルブラウザを実行することは問題になる可能性があります。特に、パイプラインが実行されている連続配信サーバーがUIを使用してブラウザーを展開できない場合（たとえば、Xサーバーが利用できないため）。この場合、xvfbのような仮想X-Serverを実行できます。

新しいアプローチは、WebDriverテストにヘッドレスブラウザー（つまり、ユーザーインターフェイスのないブラウザー）を使用することです。最近まで、PhantomJSはブラウザータスクの自動化に最もよく使用されていました。しかし、ChromiumとFirefoxそのままヘッドレスモードを実装すると、PhantomJSは突然時代遅れになります。最終的に、ユーザーが実際に使用している実際のブラウザー（FirefoxやChromeなど）を使用してサイトをテストし、開発者として便利だからといって人工的なブラウザーを使用しない方がよいでしょう。

FirefoxとChromeのヘッドレスブラウザーはどちらも新品であり、WebDriverテストにはまだ広く使用されていません。何も複雑にしたくありません。新鮮なヘッドレスモードに煩わされるのではなく、従来の方法、つまり通常のブラウザと組み合わせたSeleniumに固執しましょう。 Chromeを起動してサービスにアクセスし、サイトのコンテンツをチェックする簡単なエンドツーエンドのテストは次のとおりです。

 @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がインストールされている場合にのみ機能することに注意してください。

テストは簡単です。を使用して、ランダムポートでSpringアプリケーションを実行し@SpringBootTestます。次に、Chromeの新しい「Webドライバー」が作成され、/helloマイクロサービスのエンドポイントに移動して、ブラウザーウィンドウに「Hello World！」が印刷されていることを確認するように指示されます。いいね！

REST APIパススルーテスト

テストの信頼性を高めるには、GUIを使用しないことをお勧めします。このようなテストは、完全なエンドツーエンドテストよりも安定しており、同時にアプリケーションスタックの大部分をカバーします。これは、Webインターフェースを介したアプリケーションのテストが特に難しい場合に便利です。ウェブインターフェースさえ持っていないかもしれませんが、REST APIだけがあります（1ページのアプリケーションがどこかでこのAPIと通信するため、または単にすべてを美しくて素晴らしいと軽becauseするため）。いずれにせよ、この状況は、GUIの下ですべてをテストする皮下テストに適しています。 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を提供するサービスをテストするときに便利な別のライブラリを紹介します。REST保証ライブラリは、実際のHTTP API要求を実行し、受信した応答を評価するための優れたDSLを提供します。

まず、依存関係をyoursに追加します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!")); } } 

Springアプリケーション全体をで再度起動し@SpringBootTestます。この場合、データベースにテストデータ@AutowireをPersonRepository簡単に記録できるようにします。ここで、REST APIに友人「ミスターパン」に「こんにちは」と言うように依頼すると、楽しい挨拶が表示されます。すごい！ また、Webインターフェースがまったくない場合、エンドツーエンドのテストには十分です。

受け入れテスト-機能は正しく機能しますか？

テストピラミッドの上位に行くほど、質問をする可能性が高くなります。機能はユーザーの観点からは正しく機能しますか。アプリケーションをブラックボックスと見なし、テストの方向を過去から変更できます。

xとyを入力すると、戻り値はzになります

以下に：

与えられた権限のあるユーザーがあること

と、「自転車」の製品を持っている製品説明ページ「自転車」へのユーザーのナビゲートと押すボタンは、「カートに入れる」そして製品「自転車は、」彼のクレートにあるように

このようなテストは、機能テストまたは受け入れテストと呼ばれます。機能テストと受け入れテストは2つの異なるものであると言う人もいます。用語が組み合わされることもあります。時々、人々は言葉遣いと定義について延々と主張します。多くの場合、このような議論はさらに混乱を招きます。

その理由は次のとおりです。ある時点で、技術的な観点だけでなく、ユーザーの観点からプログラムが正しく動作することを確認する必要があります。これらのテストと呼ぶものは、それほど重要ではありません。しかし、これらのテストの存在は重要です。任意の用語を選択し、それに固執して、これらのテストを記述します。

また、BDD（動作の説明に基づいた開発）とそのためのツールに言及することもできます。 BDDと適切なスタイルのテストを書くことは、実装の詳細からユーザーのニーズにあなたの思考を変える良いトリックです。恐れて試さないでください。Cucumber

などの本格的なBDDツールを実装する必要はありません（実装できますが）。chai.jsのような一部のアサーションライブラリを使用すると、テストをBDDに近づけるスタイルキーワードを使用してアサーションを記述できます。また、このような表記法を提供するライブラリを使用しなくても、スマートで適切に設計されたコードにより、ユーザーの行動に焦点を当てたテストを作成できます。一部のヘルパーメソッド/関数は非常に成功する可能性があります。should

 # a sample acceptance test in Python def test_add_to_basket(): # given user = a_user_with_empty_basket() user.login() bicycle = article(name="bicycle", price=100) # when article_page.add_to_.basket(bicycle) # then assert user.basket.contains(bicycle) 

受け入れテストは、さまざまな詳細レベルで実行できます。基本的に、それらは十分に高いレベルであり、UIを介してサービスをテストします。しかし、テストピラミッドの最高レベルで受け入れテストを記述するための必須要件は技術的にないことを理解することが重要です。アプリケーション構造と既存のスクリプトで、より低いレベルで受け入れテストを作成できる場合は、実行してください。低テストの方が高テストよりも優れています。受け入れテストの概念は、アプリケーションの機能がユーザーにとって正しく機能することを証明するために、テストピラミッドと完全に直交しています。

研究テスト

テストを自動化するための最も勤勉な努力でさえ理想的ではありません。自動テストでは、特定の境界線のケースをスキップする場合があります。単体テストを書くことで特定のエラーを検出することが単に不可能な場合があります。一部の品質問題は、自動化されたテストではまったく表示されません（設計または使いやすさについて考えてください）。テストの自動化に関する最善の意図にもかかわらず、手動テストはいくつかの点で依然としてかけがえのないものです。


図 12.研究テストでは、アセンブリプロセス中に気付かない品質の問題を特定 し、テストスイートに研究テストを

含めます。この手動テスト手順は、作業システムの品質問題を発見できるテスターの自由と創造性を強調しています。スケジュールに少し時間をかけて、袖をまくり、アプリケーションを何らかの方法でクラッシュさせてください。破壊的思考を有効にして、プログラムの問題やエラーを引き起こす方法を考えてください。見つけたものをすべて文書化します。バグ、設計上の問題、遅い応答時間、欠落または誤解を招くエラーメッセージ、およびユーザーとしてあなたを困らせる他のものを探します。

良いニュースは、見つかったほとんどのエラーのテストを簡単に自動化できることです。見つかったエラーの自動テストを作成することにより、将来このエラーのリグレッションが発生しないことが保証されます。さらに、バグを修正する際に問題の根本原因を見つけるのに役立ちます。

探索的テスト中に、アセンブリパイプラインを静かにすり抜けた問題が見つかります。がっかりしないでください。これは、アセンブリパイプラインを改善するための良いフィードバックです。他のフィードバックと同様に、あなたの側で必ず反応してください。この種の問題を将来回避するためにどのような行動を取るべきかを考えてください。たぶん、あなたは自動テストの特定のセットを見逃したかもしれません。この時点で自動化されたテストにだらしがなかった可能性があり、今後さらに徹底的にテストされるはずです。おそらく、パイプラインでこのような問題を回避するために使用できる、ある種の素晴らしい新しいツールまたはアプローチがあります。コンベアとソフトウェア配信システム全体が各ステップで改善され改善されるように、必ず反応してください。

テストの用語との混同

テストのさまざまな分類について話すことは常に困難です。単体テスト（単体テスト）についての私の理解は、あなたのものとは少し異なるかもしれません。統合テストはさらに悪いです。一部の人々にとって、統合テストはシステム全体のさまざまな部分をテストする非常に広範な活動です。私にとって、これはかなり狭いものです。一度に1つの外部パーツとの統合のみをテストします。この統合テストを呼び出すもの、コンポーネントテストを呼び出すもの、サービステストという用語を好むものがあります。誰かがこれらは一般に3つの完全に異なるものだと言うでしょう。正しい定義や間違った定義はありません。ソフトウェア開発者のコ​​ミュニティは、テストで明確に定義された用語を確立しなかっただけです。

あいまいな用語にこだわらないでください。エンドツーエンドテスト、ワイドスタックテスト、または機能テストと呼んでもかまいません。統合テストの意味が他の会社の人と異なる場合は関係ありません。はい、私たちの業界が用語を明確に定義でき、すべてがそれらを順守できれば非常に良いでしょう。残念ながら、これはまだ起こっていません。また、テストには多くの微妙な違いがあるため、一連の個別のセットよりも幅広いテストを扱うことになり、明確な用語がさらに複雑になります。

このようにすることが重要です。あなたとあなたのチームに役立つ用語を見つけるだけです。記述したいさまざまなタイプのテストを明確に定義してください。チームの条件に同意し、各タイプのテストの範囲に関するコンセンサスを見つけます。チーム内（または組織全体）でこれらの用語に一貫している場合は、これで十分です。サイモンスチュワートは、Googleが使用するアプローチでこれをうまくまとめました。これは、名前や慣習に固執するべきではないという素晴らしいデモンストレーションだと思います。

展開パイプラインでのテストの展開

継続的インテグレーションまたは継続的デリバリを使用する場合、展開パイプラインは、ソフトウェアに変更を加えるたびに自動テストを実行します。通常、パイプラインはいくつかの段階に分かれており、プログラムが実稼働環境で展開できる状態にあるという自信を徐々に与えています。あらゆる種類のテストについて聞いたことがあるので、展開パイプラインにどのように配置するのか疑問に思うかもしれません。これに答えるには、継続的デリバリの最も基本的な値の1つ（極端なプログラミングとアジャイル開発の重要な値の1つ）について考える必要があります。クイックフィードバックです。

適切なアセンブリパイプラインは、できるだけ早くエラーを報告します。最新の変更がいくつかの単純な単体テストに違反したことを確認するのに1時間待たないでください。コンベアの動作が非常に遅い場合は、フィードバックが届いたときにすでに家に帰ることができます。パイプラインの初期段階での迅速なテストから数秒または数分以内に情報が得られるはずです。逆に、クイックテストからのフィードバックが遅くならないように、より長いテスト（通常はより広いエリアを含む）が後の段階に配置されます。ご覧のとおり、展開パイプラインの手順はテストの種類ではなく、テストの速度と範囲によって決まります。したがって、最も高速でフィードバックが得られるという理由だけで、ユニットテストと同じ段階で、最も狭くて速い統合テストのいくつかを配置することは非常に合理的です。そして、正式なタイプのテストに従って厳密な線を引く必要はありません。

テストの重複を避ける

避けるべきトラップがもう1つあります。ピラミッドの異なるレベルでテストを複製することです。才能は、多くのテストがないと言いますが、私はあなたに保証させてください：それは起こります。テストキットの各テストは、無料ではない追加の手荷物です。テストの作成と実行には時間がかかります。他の人のテストを読んで理解するには時間がかかります。そしてもちろん、テストの実行にも時間がかかります。

実動コードと同様に、単純化を図り、重複を避けてください。テストピラミッドの実装のコンテキストでは、2つの経験則があります。

1. 上位レベルのテストでエラーが検出されたが、下位レベルのテストでは検出されなかった場合、下位レベルのテストを記述する必要があります。
2. テストをピラミッドレベル全体で可能な限り低く移動します。

最初のルールは重要です。低レベルのテストは、範囲を狭め、エラーを分離して再現するのに優れているためです。それらはより速く動作し、肥大化が少なく、手動のデバッグに役立ちます。そして、将来的にはそれらは良い回帰テストとして機能します。 2番目のルールは、テストスイートをすばやく実行するために重要です。低いレベルのテストですべての条件を自信を持ってテストした場合、高いレベルのテストは必要ありません。彼はすべてがうまくいくという自信を付け加えません。過剰なテストは負担になり、日常業務で悩み始めます。テストスイートの動作は遅くなり、コードを変更した場合は、さらにテストを変更する必要があります。

別の言い方をすれば、より高いレベルのテストが、アプリケーションが正常に動作しているという自信を与える場合、そのようなテストが必要です。コントローラークラスの単体テストを作成すると、コントローラー自体の内部のロジックを確認できます。ただし、このコントローラーが提供するRESTエンドポイントが実際にHTTP要求に応答しているかどうかはわかりません。したがって、テストピラミッドを上に進め、それを正確にチェックするテストを追加しますが、それ以上のことは行いません。上位レベルのテストでは、下位レベルの単体テストですでにカバーされている条件付きロジックと境界線のすべてのケースをテストするわけではありません。高レベルのテストが、低レベルのテストでカバーされていないもののみに焦点を合わせていることを確認してください。

私は、価値のないテストを除外することに厳格です。下位レベルですでにカバーされている高レベルのテストを削除します（追加の価値を提供しない場合）。可能であれば、高レベルのテストを低レベルのテストに置き換えます。余分なテストを削除するのが難しい場合があります。特に簡単に思い付かない場合はなおさらです。ただし、サンクコストが発生する可能性があるため、[削除]をクリックしてください。もはや役に立たないテストに貴重な時間を浪費する理由はありません。

テスト用のクリーンなコードを書く

通常のコードと同様に、適切でクリーンなテストコードに注意する必要があります。開始して自動テストスイートを作成する前に、サポートされているテストコードを作成するためのヒントを次に示します。

1. , . . « » — .
2. . .
3. (arrange, act, assert) «, , » — , .
4. . DRY ( « »). , . DRY DAMP (DAMP — Descriptive And Meaningful Phrases, ).
5. , . Use before reuse .

おわりに

以上です！これは、テストを実施する理由と方法についての長くて難しい説明でした。素晴らしいニュースは、この情報には実質的に制限の規定がなく、作成しているプログラムに依存しないことです。あなたはマイクロサービス、IoTデバイス、モバイルアプリケーション、またはWebアプリケーションに取り組んでいます。この記事の教訓はすべてに当てはまります。

この記事に何か役に立つものがあればいいのですが。さあ、先に進み、サンプルコードを調べて、取得した概念をテストスイートに適用します。堅牢なテストスイートを作成するには、ある程度の努力が必要です。長い目で見れば報われ、あなたの開発者の生活がよりリラックスしたものになると信じています。

こちらもご覧ください：
「ソフトウェアテストのアンチパターン」