分度器-分度器のスタイルガイド

この章では、分度器のスタイルガイドについて詳しく学びましょう。

前書き

スタイルガイドは、2人のソフトウェアエンジニアによって作成されました。 Carmen Popoviciu、INGのフロントエンドエンジニアおよび Andres Dominguez、Googleのソフトウェアエンジニア。したがって、このスタイルガイドはCarmenPopoviciuおよびGoogleの分度器用スタイルガイドとも呼ばれます。

このスタイルガイドは、次の5つのキーポイントに分けることができます-

一般的なルール
プロジェクト構造
ロケーター戦略
ページオブジェクト
テストスイート

一般的なルール

以下は、テストに分度器を使用する際に注意しなければならないいくつかの一般的なルールです。

すでに単体テストされているものをエンドツーエンドでテストしないでください

これは、カルメンとアンドレスによって与えられた最初の一般的なルールです。彼らは、すでに単体テストされたコードに対してe2eテストを実行してはならないことを提案しました。その背後にある主な理由は、ユニットテストがe2eテストよりもはるかに高速であるということです。もう1つの理由は、時間を節約するために、重複テストを回避する必要があることです（ユニットテストとe2eテストの両方を実行しないでください）。

構成ファイルを1つだけ使用する

推奨されるもう1つの重要な点は、1つの構成ファイルのみを使用する必要があるということです。テストする環境ごとに構成ファイルを作成しないでください。使用できますgrunt-protractor-coverage さまざまな環境をセットアップするために。

テストにロジックを使用しないでください

テストケースでIFステートメントまたはFORループを使用しないようにする必要があります。そうすると、何もテストせずにテストに合格したり、実行速度が非常に遅くなったりする可能性があるためです。

テストをファイルレベルで独立させる

共有が有効になっている場合、分度器はテストを並行して実行できます。これらのファイルは、利用可能になったときに、さまざまなブラウザで実行されます。カルメンとアンドレスは、分度器によって実行される順序が不確実であり、さらにテストを単独で実行するのが非常に簡単であるため、少なくともファイルレベルでテストを独立させることを推奨しました。

プロジェクト構造

分度器のスタイルガイドに関するもう1つの重要なポイントは、プロジェクトの構造です。以下は、プロジェクト構造に関する推奨事項です。

賢明な構造でのe2eテストの模索

CarmenとAndresは、e2eテストをプロジェクトの構造に適した構造にグループ化する必要があることを推奨しました。この推奨事項の背後にある理由は、ファイルの検索が容易になり、フォルダー構造が読みやすくなるためです。このステップでは、e2eテストを単体テストから分離します。彼らは、次のような構造は避けるべきであると推奨しました-

|-- project-folder
   |-- app
      |-- css
      |-- img
      |-- partials
         home.html
         profile.html
         contacts.html
      |-- js
         |-- controllers
         |-- directives
         |-- services
         app.js
         ...
      index.html
   |-- test
      |-- unit
      |-- e2e
         home-page.js
         home-spec.js
         profile-page.js
         profile-spec.js
         contacts-page.js
         contacts-spec.js

一方、彼らは次のような構造を推奨しました-

|-- project-folder
   |-- app
      |-- css
      |-- img
      |-- partials
         home.html
         profile.html
         contacts.html
      |-- js
         |-- controllers
         |-- directives
         |-- services
         app.js
         ...
      index.html
   |-- test
      |-- unit
      |-- e2e
         |-- page-objects
            home-page.js
            profile-page.js
            contacts-page.js
         home-spec.js
         profile-spec.js
         contacts-spec.js

ロケーター戦略

以下は、テストに分度器を使用する際に注意しなければならないロケーター戦略です。

XPATHは絶対に使用しないでください

これは、分度器スタイルガイドで推奨されている最初のロケーター戦略です。同じ理由は、マークアップは非常に簡単に変更される可能性があるため、XPathには多くのメンテナンスが必要なためです。さらに、XPath式は最も遅く、デバッグが非常に困難です。

by.modelやby.bindingなどの分度器固有のロケーターを常に優先する

by.modelやby.bindingなどの分度器固有のロケーターは短く、具体的で読みやすいです。それらの助けを借りて、私たちのロケーターを書くことも非常に簡単です。

例

View

<ul class = "red">
   <li>{{color.name}}</li>
   <li>{{color.shade}}</li>
   <li>{{color.code}}</li>
</ul>

<div class = "details">
   <div class = "personal">
      <input ng-model = "person.name">
   </div>
</div>

上記のコードでは、次のことを避けることをお勧めします-

var nameElement = element.all(by.css('.red li')).get(0);
var personName = element(by.css('.details .personal input'));

一方、以下の使用をお勧めします-

var nameElement = element.all(by.css('.red li')).get(0);
var personName = element(by.css('.details .personal input'));

var nameElement = element(by.binding('color.name'));
var personName = element(by.model('person.name'));

分度器ロケーターが利用できない場合は、by.idとby.cssを優先することをお勧めします。

頻繁に変更されるテキストのテキストロケーターは常に避けてください

ボタン、リンク、ラベルのテキストは時間の経過とともに頻繁に変化するため、by.linkText、by.buttonText、by.cssContaningTextなどのテキストベースのロケーターは避ける必要があります。

ページオブジェクト

前に説明したように、ページオブジェクトは、アプリケーションページの要素に関する情報をカプセル化します。これにより、よりクリーンなテストケースを作成できます。ページオブジェクトの非常に便利な利点は、複数のテストで再利用できることです。アプリケーションのテンプレートが変更された場合は、ページオブジェクトを更新するだけで済みます。以下は、テストに分度器を使用する際に注意が必要なページオブジェクトに関するいくつかの推奨事項です。

テスト対象のページを操作するには、ページオブジェクトを使用します

ページオブジェクトを使用して、テスト対象のページと対話することをお勧めします。これは、テスト対象のページの要素に関する情報をカプセル化でき、再利用もできるためです。

ファイルごとに常に1ページのオブジェクトを宣言する

コードをクリーンに保ち、物事の検索が容易になるため、各ページオブジェクトを独自のファイルで定義する必要があります。

ページの終わりに、オブジェクトファイルは常に単一のmodule.exportsを使用します

1つのクラスのみをエクスポートする必要があるように、各ページオブジェクトで1つのクラスを宣言することをお勧めします。たとえば、次のオブジェクトファイルの使用は避ける必要があります-

var UserProfilePage = function() {};
var UserSettingsPage = function() {};
module.exports = UserPropertiesPage;
module.exports = UserSettingsPage;

ただし、その一方で、以下を使用することをお勧めします-

/** @constructor */
var UserPropertiesPage = function() {};

module.exports = UserPropertiesPage;

必要なすべてのモジュールを上部で宣言します

モジュールの依存関係が明確になり、見つけやすくなるため、必要なすべてのモジュールをページオブジェクトの上部で宣言する必要があります。

テストスイートの開始時にすべてのページオブジェクトをインスタンス化します

テストスイートの最初にすべてのページオブジェクトをインスタンス化することをお勧めします。これにより、依存関係がテストコードから分離され、スイートのすべての仕様で依存関係を利用できるようになります。

ページオブジェクトでexpect（）を使用しないでください

すべてのアサーションはテストケースで実行する必要があるため、ページオブジェクトでexpect（）を使用しないでください。つまり、ページオブジェクトでアサーションを作成しないでください。

もう1つの理由は、テストの読者は、テストケースのみを読むことで、アプリケーションの動作を理解できる必要があるためです。