🐗 👨🏾‍💼 🦗 テスト自動化の設計パターン 🏣 🧓🏽 🤙🏻

「クールなテストを受けて書くことはできません。 1つのテストを作成できますが、これらのクールなテストの数が増えても、これらのクールなテストを作成する人の数が増え、スピードや時間を失うことはありません...」

この考えは、赤い糸でカットの下の素材を通過し、おそらく説明を必要とします。この記事は、ニコライ・アリメンコフの報告に基づいています。ニコライ・アリメンコフは、ウォーミングアップだけでなく、テストを書く方法についてのアレクセイ・ヴィノグラドフとの議論の後、直接コード法を使用するかパターンを使用しました。 PageElement、Steps、PageObject以外のパターンが必要ですか？！パターンがコードを複雑にし、不要な（？）ボイラープレートシートの作成に時間を費やすと誰かが決めたのはなぜですか？ソリッドはあなたを喜ばなかった？しかし、それらはすべて、開発者コミュニティのすべての蓄積された経験を考慮して作成され、彼らは何をしていたかを知っていました。

Nikolay xpinjection Alimenkovは、有名なJava開発者、Java技術マネージャーおよび配信マネージャーであり、XP Injectionの創設者です。彼は現在、独立した開発者およびコンサルタントであり、アジャイル/ XPのコーチであり、さまざまな会議のスピーカーおよび主催者です。

テスト自動化には独自のタスクセットがあるため、この領域に役立つデザインパターンのセットがあります。報告書では、ニコライがすべての有名なパターンについて語り、実際の例を使って詳細に説明しています。

この資料は、「テストパターンの設計パターン」と題されたHeisenbug 2017 PiterカンファレンスでのNikolai Alimenkovによるプレゼンテーションに基づいています。スライドはこちらです。

設計パターンは議論の余地のあるトピックです。この質問をグーグルで検索すると、このプレゼンテーションにはないデザイン自動化のデザインパターンの他の例がたくさんあります。この資料では、個人的に対処しなければならなかった13年間の個人練習で蓄積されたすべてのパターンを収集したいと思います。プレゼンテーションには、著者が疑わしいと思うパターン、役に立たないパターン、または遭遇しなかったパターンは含まれていません。同時に、このプレゼンテーションは新しい例とともに時間とともに拡大しています。

しかし、最初に、設計パターンの簡単な定義。

設計パターンとは何ですか、なぜこれが存在するのですか？

「良いデザインパターン」や「悪いデザインパターン」といったものはありません。「設計パターン」という用語自体は、問題と提案された解決策の定式化によって作られました。したがって、あなたが出会うすべてのパターン-開発中、テスト中、他の何かで、それが発明された問題を共有しない場合-これはそれが悪いまたは「流行遅れ」であることを意味しません、それはあなたのためだけではありません合う。問題がこのデザインパターンと何らかの形で一致し、重なっている場合は、検討する必要があります。

したがって、デザインパターンを聞いたという理由だけでプロジェクトにデザインパターンをもたらすだけでなく、その目的、問題、それらがどのように役立つかを理解することが重要です。

設計と開発の自動化には多くの問題があり、これらの問題に直面すると、人々はパターンを策定しました。古典的なパターンは、元々、Design Designsという本を出版した4人によってかなり前に策定されました。

この本は、オブジェクト指向の世界で当時遭遇したすべてのパターンを定式化します。問題があります-解決策があり、長い間、デザインパターンのこの概念は成長し、発展し、新しいパターンで補充されました。

今日、問題が蓄積している他の領域で同様のパターンが出現する傾向があります。

テスト自動化のほぼすべてのパターンの主な要因は、上記のスライドの要素です。信頼性、わかりやすさ、柔軟性、保守性、安定性、およびテストで重要な他の同様の要素です。

これらの要因のほとんどは、概念の分離の影響を受けます。機能テスト、統合テスト、単体テストのいずれにおいても、テストロジック、テストデータ、アプリケーションドライバ、または技術的詳細、技術的部分-直接的な相互作用を担当する部分の3つのコンポーネントが常に存在しますアプリケーション、コード（関数の呼び出し、画面のクリックなど）。

これらの部分が十分に分離されている場合、テストは上記の要因にうまく入り始めます。この場合、それらは操作がはるかに簡単で、理解と保守がはるかに簡単だからです。

すべてのパターンをいくつかのグループに分けました。

構造パターン

最初のグループは構造パターンです。その主なタスクは、テストのコードを構造化することです-サポートを簡素化し、重複や混乱の問題を回避します。したがって、同じ問題を扱うテストエンジニアが理解し、変更しやすくなり、保守しやすくなります。

そのようなパターンの最初のグループはPage Objectです。なぜ必要なのですか、問題は何ですか？

問題の最初の部分：アプリケーションの論理構造があり、コードでテストを作成するとき、現在の正確な位置がわかりません。テストでUIが直接表示されません。ステップ15の後、どこで、どのページで、どのアクションを実行できますか。たとえば、ステップ15の後に再度ログインできますか？

問題の2番目の部分：技術的な詳細（この場合、Webについて言えば、これらはブラウザーの要素、これまたはその機能を実行する要素）を分離し、テストのロジックを分散して、テストのロジックがきれいで透明なままになるようにします。この情報は別の場所に保存されていました。

最後に、最後の要因：これらのページに入れたコードを後で再利用したいと思います。多くのスクリプトが同じページを通過する場合、このコードを一度書いた後、自分でこのコードを書くことはなく、それを呼び出すことになるので、非常に論理的であるため、非常に単純化されますテストを書く。

Page Objectが解決に役立つ3つの問題を以下に示します。テストが2、3しかない場合、この問題は発生しません。適用できる規模はありません。 5〜10〜15のテストがある場合、この問題がある場合とない場合があります。したがって、このパターンが実行中のものと一致するかどうかを理解する必要があります。

Pageオブジェクトを簡単に見てみましょう。ラベルに関係なく、いくつかの要素を持つページがあります（この例では、@ FindByアノテーションを使用しています）。好きなアノテーションを使用できます。この論理ページのすべての要素を1つの場所にまとめ、追加のドメインメソッドを提供します。このメソッドは次のようになります。

たとえば、ドメインメソッドregisterAccountがあり、そこにuserNameと金額（金額）を表示します。これにより、あるフィールドに名前を入力し、別のフィールドに金額を入力し、ボタンをクリックすると、新しいアカウントが作成されます。または、たとえば、名前の最初の文字を入力します（以下の例）。

したがって、テストは非常に単純に見えますが、これはすべてテストに含まれておらず、合格し、テストロジックがクリアされます。このパターンが発明されたものを手に入れました。

これが最も簡単なパターンです。どうぞ

流Fluな/一連の呼び出し

次に解決する問題は、たとえばログインページで何かを呼び出すときです。ログインページでさらに電話をかけることはできますか？あなたは知らない。

ここで、たとえば50個のメソッドがあるページを想像してください。そして、それらすべてをすぐに呼び出すことができるのか、それらの一部だけを呼び出してから、他の呼び出しを行うことができるのかがわかりません。たとえば、まだ文字を入力しておらず、自動プロンプトが表示されない場合、名前表示ダイアログを使用できますか？この対話はまだ存在しないため、おそらくそうではありません。

この問題は、ページ数、要素数、メソッド数を蓄積し始め、アクションの特定のフローを構築したい場合に重要です。次のアクションを実行するたびに、自動プロンプトが表示され、すべてが明確になります。

したがって、「accountsPage、最初の文字を入力して、accountsPage、プロンプトを待って、accountsPage、名前を選択する」というコードの代わりに-ここで、簡単に入れ替えることができます。間違えるのは非常に簡単です。

代わりに、このアプローチを使用することをお勧めします。このアプローチでは、アクションを実行するたびに、ユーザーがいるコンテキストが返されます。同じページ、リロードされたページ、別のページ、論理コンポーネントなどです。

通常、このチェーンを中断する場合、このメソッドでは、文字列、数字、または何か他のものなどの値を指定します。これにより、先に進むことができないことを示唆します。つまり、これは最後の最終操作であり、その後はチェーンを継続できません。その後、さらにどこに行きたいかを考え、手でこのアクションを実行する必要があります。

これは非常に簡単に実装されます。ページオブジェクトまたはこのパターンを適用できる他の場所で、戻り値を使用します。戻り値は、このオブジェクトまたは作業を継続する他のオブジェクトです。

コードが非常にコンパクトになるわけではありません-いくつかの重複がコードから削除され（この場合、各ページにいるたびに言う部分が削除されます）、よりわかりやすく透明になります。

工場/ページ工場

次のパターンはページファクトリ、または単にファクトリです。これは、ページだけでなく適用できるためです。このパターンが生じたのは、ページを初期化するために、「新しいページ」と言う、開く、または何か他のものを言う以上のことをする必要がある場合があるためです。つまり、このページにはまだ追加のロジックがいくつか隠されており、どこかに登録したり、要素を初期化したりする必要があります。

この場合、このページを作成した人からこの情報を非表示にして、非表示にする必要があります。これは、誰にとっても重要ではない技術情報です。

これは、ファクトリアプローチが適用される場所です。この場合、このアプローチがあります。「新しいMainPage」と言い、そこにドライバーを渡し、「page、open」と言います。この発見に何か特別なことをしたい場合、このページを開いて初期化して新しいものにするため、ファクトリメソッドになるオープンメソッドに入れる必要がありますこれをコンストラクタに追加することもできますが、これもあまり良くないかもしれません。

したがって、別のアプローチがあります-単にファクトリを指定する場合（たとえば、Webドライバー用のJavaである古典的なページファクトリーを指定しました）、ページファクトリー、Init要素を注文するだけで、クラスのインスタンスを取得できますこのページにあるすべての初期化された要素を持つページ。

ここで機能する追加の要素は、すべての要素の初期化です。このようなページを開くことができ、メインページから開始する必要はありません。

「工場」は異なります。独自のメソッドを作成したり、ファクトリメソッドを使用したりできます。これが行われる理由の本質を理解することが重要です。

ページ要素/アイテムの複合リストリンクメニューパネルチェックボックス

重要なWebまたはデスクトップアプリケーションは、テストで何度も何度もロジックを記述する要素を繰り返して構成されます。タブレットでの作業を開始すると、常にメニュー、チェックボックスがあります。テストで作業する場合、これらのトップリンクは、互いに関連しておらず、独自の独立した現実に住んでいるとはほとんど考えていません。これはメニューであり、要素が配置されたパネル、リンク、要素のリストなどであることを理解しています。

この理解のおかげで、要素との通信コストを大幅に削減できます。これは、メニューとそれを操作するロジック全体を一度実装した場合、使用可能なコンポーネントを簡単に大幅に簡素化および作成できるため、再利用でき、テストの開発時間を短縮できるためです

重複コードなし

問題は、どこにでも重複が見られることであり、これらの重複を排除したいということです。

これは、 ページ要素パターンの表示方法です。前のページの代わりに、フィールド名、量などの代わりに高レベルのウィジェットが挿入される改善されたページがあります。これらの最初のものは、送信、「フィールドに値を入力する」、検証など、すべてのフォームに特有のアクションを実行できるフォームです。2番目はプレートです。

タブレットでは、見出し、列、行があるため、すべてがより興味深いものになります。すべてのテーブルに固有の多くのドメインコマンドがあります。例外なく、それらがどのように実装されていても、このテーブルがブラウザでどのように見えても関係ありません。そのようなラベルがある場合、要素をこのように配置すると、ページの処理が大幅に簡素化されます。

私の観点からすると、次のパターンはかなり疑わしいですが、多くの人がそれを使用していることは確かです。

ローダブルコンポーネント

問題は、同じWebドライバーで長時間、あるページに移動すると、「ページの再読み込み」の概念がないことです。さらに、「ページの再読み込み」などの機能がない、いわゆる1ページアプリケーションが増えています。

つまり、論理ページを開いてこのページの任意の要素を操作する場合、このページが論理的にロードされるのを待って確認する必要があります。あなたの行動のそれぞれの後に、あなたは何か、つまり何かへの期待を独特の待ち方をすべきであることがわかります。多くの人々がフレーマーがあなたのためにそれをすることを期待するので、これはしばしば待機によって行われません。たとえば、Webドライバーには暗黙的な待機という概念があります。つまり、ユーザーの場合は、ブラウザーの側からその要素を暗黙的に待機します。

「OK、これで十分です」と言う人もいますが、暗黙の待機が小さく、それがうまくいかない場合は、何かを徹底的に待機するときにいわゆる明示的な待機が表示されます。、論理ページを変更しますが、waitによって補完されます。何かをする-待つ、何かをする-待つ

このようなテンプレートはテストロジックを非常にロードします。説明自体にテストがないため、「そのページに移動」と言って、この期待をオンにします。

これを回避するために、ロード可能なコンポーネントから作成するすべてのページを継承し、ロードされたメソッドをオーバーロードできるため、この期待を非表示にしてページ内の各ページに指定することができます。この場合、ロジックを1か所にカプセル化します。同じページを5か所で呼び出し、他のどこにもこの待機を自分の手で書くことはありません。これが、このパターンが発明されて存在する理由です。

なぜ彼は物議を醸しているのですか？私の観点からは、ほとんどの場合、暗黙的な待機を伴うデフォルトの動作に依存していますが、これで十分です。そのため、どのコンテキストで適用できるかを調べる必要があります。

戦略と呼ばれる次のパターンは、同じもの（シーケンスまたはアクション）を複数実装する場合に必要です。コンテキストに応じて、ここでこの実装を置き換えることができます。

これは、たとえば、検証で使用できます：いくつかの抽象検証メソッドがあり、この戦略を直接適用します。また、ある種の計算アルゴリズムを使用することもできます。複雑なアルゴリズムまたは単純なアルゴリズムを使用できますが、コードに直接入力したくないため、特定の戦略の特定の実装を置き換える柔軟性が得られません。

この特定の場合-上記のスライドには、ユーザー登録の戦略があります。この戦略の最初の実装では、このためにブラウザーを使用します。ページを開いてフィールド、「登録」ボタンを表示し、URLから出力でIDを受け取り、ユーザーオブジェクトを返します。2番目はAPIを通過します。

どちらが速いと思いますか？

確かに2番目：後で97％に変更することにした場合、このコードを手でどこにでも書きたいですか？おそらくない。

おそらく、どこでも変更する必要はないでしょう。結局のところ、どこかでユーザー登録を本当に確認する必要があります。Webで確認しなければ、すべてが悲しくなります。したがって、ある場所で1つの戦略を使用し、別の場所で別の戦略を使用したいと思います。テストロジック自体は、どの実装であるかを示さず、その実装を使用するインターフェイスに依存するため、冷静に行うことができますこれをテスト中に置き換えます。

このため、私は概念の柔軟性と分離を手に入れました。また、これらすべてをサポートする必要がある人々の生活を簡素化しました。

データパターン-データパターン

あなたが元の写真で見たように-なぜ私たち全員がこれをしているのか-データの三角形がありました。いわゆるボイラープレートコード（テストを詰まらせるガベージコード）の量を削除するために、テストロジックからデータとデータ管理を可能な限り削除したいと思います。これにより、ロジックがさらに透明になり、これらの自動テストを作成する人のサポートが容易になります。

これがすべてのデータパターンの動機です。

値オブジェクト

このグループの最初のパターンは非常にシンプルで、皆さんがそれを使用したと思いますが、残念なことに、これが無視され、非常に難しいことが判明したプロジェクトをたくさん見ました。

パターンの本質は次のとおりです。論理的に結合された複数のオブジェクトがある場合（この例ではregisterUserがあり、5つのパラメーター-名、姓、年齢、役割など）を渡します。私は個人的に約100個のパラメータを作成する方法を見て、便利な限りこれで静かに暮らしました-推測することしかできません。パラメーターは論理的に示されていましたが、この接続はどこにも示されていませんでした。

この場合、追加のValueObjectを導入することでこれを変換できます。これは、論理ユーザーと呼ばれ、このすべての情報を集約します。

なぜValueObjectなのか？不変です。作成後、変更することはできません。これはタスクであるため、ポイントAからポイントBにデータを転送するためのものであり、変更可能またはサードパーティの効果をもたらすためではありません。

このようなユーザーの作成と操作を簡素化するために、Javaを使用している場合、Lombokツールを使用できます。これにより、データを取得するゲッターのみを使用してコンパクトな要素を簡単に作成できます。コンストラクタが必要な場合-あらゆる量のコンストラクタが生成されるのと同様に、このコードを手で記述する必要はありません。

ビルダー

次のパターンはビルダーです。大きなオブジェクトがあり、このオブジェクトをまったく異なる方法で構成できるとします。最初の方法に進み、バリエーションがある数のコンストラクターを追加できます。新しいバリエーションに出会うたびに、新しいコンストラクターを追加できます。その結果、コンストラクターは100,500になり、どのコンストラクターをいつ呼び出すかは完全に不明確になります。

これを単純化するには、コンストラクターをより理解しやすくし、他に何を構成できるかを自動的にプロンプトする機能を追加します。Builderパターンが使用されます。その実装は次のとおりです。

Builderをクラスターごとに取得します。この場合、ドメインメソッドを使用してこのクラスターを構成します。ContactPoints、ポート、再試行回数、メトリック構成を追加し、その後、最後にビルドと言い、オブジェクトを取得します。自動テストで使用できます。

すべての必要なフィールドを設定する必要がないため、これは非常に便利です。現時点で関心のあるフィールドのみを設定でき、操作するオブジェクトの構成を簡素化します。

オブジェクト/マッチャーのアサート

次のパターンは誰もが話しますが、それを使用する人はほとんどいませんが、アサートオブジェクト、つまり「マッチャー」です。私たちには古典的なアプローチがあります-私たちはユーザーを引き抜いて、彼らにいくつかのチェックをしたいと思います。従来のアプローチは、多くの異なるチェックを行うという点で異なり、それらはすべて1つのドメインエンティティに関連しています。

これらのチェックの背後に、上記の例には3行あります。チェックの論理名はありません。失われます。具体的に何をチェックしますか。そして、この特定のコレクションには特定のロールを持つユーザーが1人しかいないことを確認しますが、それ以外の場合は何が問題なのか理解できないため、それをいくつかのチェックに分割する必要があります：最初に、このコレクションでのみ確認する必要があります1人のユーザー、そして彼がそのような役割を持っていること。しかし、論理的には、この主張を書いたときに頭の中にあったため、この情報は私たちに隠されていますが、現在、この情報は再現されていません。

この設計パターンは、繰り返しの構造の形でアサーションを実装する必要があることを示唆します。これにより、将来必要になった場合、そのようなアサーションを記述できなくなります。別のテストでは、ユーザーが1人しかいないことを確認する必要があるかもしれません、ただし別のロール、またはこのロールを持つすべてのユーザーなど。

コードの書き換えを避け、同時にドメインロジックを配置しようとします。したがって、この方法でそれを行うことをお勧めします。まず、アサーションのグループを割り当てます。これには、ユーザーとのすべての可能なアサーションを作成する個別のクラス（この場合はUserAssert）の作成を使用できます。 UserAssert自体の静的メソッド。assertThatを指定し、このアサーションを返します。このアサーションに対して、さらにチェックを行うことができます。見た目は美しく、以前よりもはるかに読みやすくなり、チェック内のコードはまったく同じままであり、再利用のみが可能であることを誰もが理解しています。

これに対して静的メソッドを作成できます。これは、Hamcrestライブラリと他のFast assertライブラリによって実装される完全に独立した方向です。このアプローチを使用して、アサーションのチェーンを作成し、再利用できる独自のassertを記述できます。

基本サイクル用にすでに膨大な数のアサーションが記述されているため、最初から記述する必要はありません。ここでは、ビジネスアサーションについて説明します。ビジネスタスクを策定する基本的なタイプの最も単純な機能アサーションのグループについて、ビジネスの観点から正確に何を確認しますか。

データ登録

次のテンプレートはより興味深いものです。彼の問題はこれです：テストでデータを使用し始め、それらが互いに独立していると仮定して、どういうわけかそれらを互いに解こうとしますが、結果として依存テストを取得するという結論に達することができます互いの論理を「知る」。たとえば、このテストではユーザー1、2、3を使用していることがわかり、その後、「すべてのユーザー1、2、3が私に割り当てられ、他のユーザーはそれを使用しません」というメッセージが表示されます彼を別の場所に連れて行き、そのような問題を知らない。

データレジストリアプローチにより、一意のデータを生成し、その一意性を追跡できます。この場合、最も単純なアプローチを使用します。「一意のユーザーを指定」し、静的増分マルチスレッドカウンターを使用します。これは常に1ずつ増加し、一意のユーザーを保証します。

特定のパターンはより複雑になる可能性があります。たとえば、データベース、ファイル、事前定義されたユーザーセットなどから取得できます。一番下の行は、テストで作業するすべての人が、いくつかの一意のデータで作業を開始する前に、レジストリユーザーまたはこのレジストリから他のデータを要求し、ランダム化アルゴリズム自体を知らないが、彼が受け取ることを常に確信していることですこのデータは他のテストから独立しています。これにより、データに応じた交差点のエラーによるテストのセキュリティが向上します。

オブジェクトプール/フライウェイト

次のパターンは既知であり、さらに少数の人々によって使用されています。フライウェイトは、古典的なパターンに由来するパターンの名前であり、作成が困難なオブジェクトまたはオブジェクトのセットに関する問題を解決します。毎回作成する代わりに、それらを取得して使用し、その後、取得した場所から同じプールに戻ります。

このパターンのおかげで、たとえばブラウザプールを実装できるなど、多くの興味深いものを実装できます。多くの苦情-ブラウザが立ち上がる間、最初のページが読み込まれる間、プロファイルがコピーされる間など、Webテストは遅くなります。

ブラウザーをテストで直接作成する必要はありません。代わりに、必要なブラウザーの数が構成されているバックグラウンドプールを使用できます。このプールでは、ブラウザーが戻ったときにクリアして他の操作を行いますが、すべてがバックグラウンドで実行されます、テストスレッドの実行と並行して。また、ブラウザプールから自分用の新しいブラウザを要求すると、使用可能なブラウザのみがテストに提供されます。

これにより、構成部分と時間をテストの実行時間からブラウザー構成に移すことができるため、テスト自体でブラウザーまたはその他のリソースを準備するコストを大幅に削減できます。

ページを使用する別の例：常に同じページから開始する場合、ページが開くのを待つ必要はありません。ページのプールを作成し、そこからページをリクエストできます。つまり、既にそこに開いて、ブラウザインスタンスで待機していることを意味します。また、開いているページでロジックを既に開始しており、オープン自体は非表示のバックグラウンドプロセスで行われます。

最後に、このパターンのより複雑な使用の典型的な例は、データベースインスタンスのプールがある場合です。実際のデータベースを使用する代わりに、さまざまなポートで必要な量のデータベースコンテナーの必要なセットを選択します。これは、Dockerまたは他の利用可能な仮想化ツールを使用して、データベースで作業した後に非常に簡単に実行されます、あなたはそれを「消し」、プールで新しいものを上げました。これにより、常にクリーンな作業用データベースを使用でき、データベースの分解やクリア、データの収集とロードなどを行う必要がありません。

データプロバイダー

次のパターンであるデータプロバイダーは、おそらく誰もがよく知っているものです。データドリブンテストを作成し、同じテストロジックを異なるデータで実行したい場合は、外部ソース（この場合はxls）またはCSVからデータを読み込むか、プルしますいくつかのサービスから、またはあなたはそれらをここに縫い付けています。