TestCafe のアーキテクチャ

how-it-works.ja.md

どのように動作しているのか

TestCafe が登場する前は、実際のブラウザで動作するエンドツーエンドの Web テスト ツールは、これらのブラウザを外部から駆動してユーザー アクションをエミュレートすることに依存していました。ただし、このアプローチには重大な欠点がありました。

• サードパーティ ツールへの依存。そのため、すべてのテスト環境で追加のドライバー、SDK、ライブラリをインストール、構成、保守する必要がありました。
• ブラウザのサポートが制限されています。使用可能なブラウザとプラットフォームの範囲は、ドライバでサポートされているものに制限されていました。
• ボイラープレート コード。 これらのテスト ツールは、テスト実行全体を通じて同じブラウザ インスタンスで機能したため、テストされた Web アプリの状態 (Cookie、ストレージなど) はテストから終了まで持続しました。テスト。その結果、エンドツーエンド テストには、テスト間の干渉を避けるために状態をクリアする大量の定型コードが含まれます。
• 自動化が低い。 従来のツールは、テストされたページと直接対話できませんでした。ユーザーのテスト コードがアプリ コードに介入しないという事実は利点でしたが、テスト ツール自体はページ内で動作することで恩恵を受ける可能性があります。これにより、ツールで多くの日常的なタスクを自動化できるようになります。

テストカフェは違う

TestCafe アーキテクチャを定義した考え方は、ブラウザでエンドツーエンドのテストを実行するために外部ドライバーは実際には必要ないというものでした。代わりに、ページはユーザーのアクションをエミュレートするすべてのテスト スクリプトを実行できます。これにより、最新のブラウザを搭載したあらゆるデバイス上で実行できる、真のクロスブラウザおよびクロスプラットフォームのテストが可能になります。このビジョンは最終的に次の設計コンセプトに発展しました。

クライアントサーバーアーキテクチャ

TestCafe は、「サーバー側」の Node.js 環境でユーザーが作成したテスト コードを実行します。ユーザー アクティビティをエミュレートするスクリプト (オートメーション スクリプト など) は、同じデバイスまたは別のデバイス上のブラウザのテスト済みページ内で実行されます。これは「クライアント側」です。

このハイブリッド アプローチにより、TestCafe テストでは、ブラウザ スクリプト (組み込みの待機、モバイル テスト) とスタンドアロンのサーバー側コード (アプリのサーバーおよびテスト環境へのアクセス、テスト実行のより適切な制御) の利点が組み合わされます。

Node.js API

テスト コードでは、最終的にページ上のユーザー アクションに変換されるわずか数十のメソッドで構成されるコンパクトな API を使用します。このサーバー側コードは Node.js で実行されるため、テストは JavaScript または TestCafe が JavaScript にコンパイルできる言語 (TypeScript や CoffeeScript など) で作成する必要があります。

簡潔な API により、テストの作成、読み取り、保守が簡単になります。一般的な Web 言語のサポートにより、ほとんどのユーザーが既存のスキルを使用できるようになり、新規ユーザーの学習曲線が最小限に抑えられます。

ページプロキシ

自動化スクリプト (クライアント側コード) をブラウザーに提供するために、TestCafe は内部でリバース プロキシを実行します。テストされたページをサーバー上でプロキシし、そのコードにスクリプトを挿入します。

スクリプト インジェクションにより、モバイル テスト、自動待機、スマート認証のユーザー ロールなどの TestCafe の主要な機能がすぐに有効になります。

分離されたテスト

各テストは、ブラウザーがクリーンな状態から始まります。 Cookie とストレージがリセットされ、空のユーザー プロファイルが使用され、テストされたページがリロードされます。これにより、追加の定型コードを使用せずにテスト間の干渉を防ぐことができます。

クライアントサーバーモデル

クライアント/サーバーの設計は、私たち自身の経験に基づいています。 TestCafe の初期バージョンでは、ユーザーが注入されました。コードをページに直接テストします。これが Web ドライバーから解放される最も簡単な方法のように思えました。その後、このアーキテクチャではテスト コードの機能が制限されていることがわかり、テスト エンジンを分離することにしました。すべてのテスト アクションに対して Node.js API を公開し、サーバー プロセスでテスト スクリプトを実行するテスト ランナーを実装しました。 TestCafe は、その側で自動化スクリプト (クライアント コード) を生成し、ブラウザーで実行します。

サーバーサイドのテストコードを使用する理由

Node.js テスト コードを使用すると、テスト環境をより詳細に制御できます。

• データベースを準備したり、テストから Web サービスを起動したりできます。
• サーバーのファイル システムにアクセスして、データ サンプルを読み取ったり、アップロードされたファイルを確認したりできます。
• テストでは、すべての Node.js 機能と外部 Node.js モジュールを使用できます。
• テスト ロジックが自動化スクリプトから分離されたため、テストがより高速になり、より安定しました。
• TestCafe はユーザーが作成したコードを「そのまま」挿入しないため、テスト コードはページの実行を中断できません。
• async/await などの最新の構文機能がサポートされています。

Node.js コードはサーバー上で実行されるため、DOM やブラウザ API などにすぐにアクセスすることはできません。このトレードオフは、カスタムのクライアント側関数のサポートによって補われました。

テストカフェ API

テスト コードは、TestCafe API メソッドを使用して、テストされたページと対話します。インタラクションには主に次の 3 つのタイプがあります。

• ページ上でアクションを実行します。 TestCafe は、クリック、ダブルクリック、入力、ホバー、ドラッグ アンド ドロップ、テキストの選択、アップロードなど、すべてのエンド ユーザー アクションをエミュレートできます。API は、各アクションに対して 1 つの単純なメソッドを提供します。

await t
    .typeText('#input', 'Hello world!')
    .click('#submit-button');

• アサーションを実行します。アサーションを使用すると、要素のプロパティやその他のページ パラメーターを検証できます。 「等しい」、「含む」、「より大きい」、「より小さい」、「一致」などの条件を使用できます。 「種類」など

await t
    .expect(input.exists).ok()
    .expect(input.value).eql('Hello world!');

• 要素を選択セレクターメカニズムを利用します。

const downloadSection = Selector('.download-section');
const downloadButton  = downloadSection.child().withText('Download');

TestCafe API で使用できるその他の機能には、リクエスト モック、迅速な認証のためのユーザー ロール、ダイアログ処理、デバッグなどがあります。

カスタムクライアント側コード

高度なシナリオでは、TestCafe を使用して、テストされたページで実行されるコードを作成できます。カスタムのクライアント側コードを使用して、次のタスクを実行できます。

• ページ要素を識別します。 複雑な CSS セレクターであっても、現実世界の Web アプリでページ要素を識別できるほど強力であるとは限りません。 TestCafe を使用すると、DOM 要素またはノードを返すクライアント側のコードに基づいてセレクターを作成できます。このコードはサーバー側のテスト内に直接記述できます。どうやら、これではライブ DOM オブジェクトが Node.js 環境に取り込まれないようです。 TestCafe は、ページ要素を見つける必要があるときにブラウザでこれらの関数を実行します。

const element = Selector(() => {
    return document.querySelector('.class-name');
});

await t.click(element);

• データを取得します。 クライアント側から任意のシリアル化可能なオブジェクトを返すクライアント関数を作成できます (これには、JSON に変換できるすべてのオブジェクトが含まれます)。セレクターとは異なり、テスト コードはこのクライアント関数が返すオブジェクトにアクセスできます。クライアント関数から取得したデータを使用して、ページ状態のさまざまなパラメータを検証できます。

const getUrl = ClientFunction(() => {
    return window.location.href;
});

await t.expect(getUrl).eql('https://example.com');

• スクリプトを挿入します。 TestCafe では、テストされたページにカスタム コードを挿入することもできます。挿入されたスクリプトを使用して、ヘルパー関数またはモック ブラウザ API を追加できます。

fixture `My Fixture`
    .page `https://example.com`
    .clientScripts('assets/jquery.js', 'scripts/location-mock.js');

ベスト プラクティス ルールは、カスタム クライアント側コードでのページの変更を避けることであることに注意してください。 DOM を変更するアクションは、TestCafe の内部メカニズムを妨げずに手動で実行する信頼できる方法がないため、サーバー側 API を通じてのみ実行する必要があります。ルールは、ページを探索し、情報を見つけてサーバーに返すためだけにクライアント側のコードを使用することです。

リバースプロキシ

TestCafe テストを実行すると、ブラウザのアドレス バーに Web サイトに属さない URL が表示されることに気づくかもしれません。これは、TestCafe がテストされたページをプロキシするためです。

TestCafe リバース プロキシ (testcafe-hammerhead) はコンピュータ上でローカルに実行されます。これにより、TestCafe は、既存のページ コードも通信先のリソースもページが変更されたことを認識できない方法で自動化スクリプトを追加できます。

TestCafe がテストされたページをプロキシするとき、自動化スクリプトを挿入し、内部 (マークアップ、スクリプトなど) のすべての URL をプロキシを指すように書き換えます。ブラウザーがこれらの新しい URL を参照すると、元のリソースもプロキシされ、同じ方法で変更され、自動化がシームレスに続行されます。また、TestCafe はブラウザー API をモックして、ページ コードの残りの部分から自動化スクリプトを隠します。

プロキシ メカニズムにより、テスト コードに対してもページが元の URL でホストされているように見えます。これが、テストで Web サイトの URL を使用し、ブラウザのアドレス バーに表示される URL を無視できる理由です。

自動化スクリプト

TestCafe 自動化スクリプトは、テストされたページでのエンドユーザーのアクションをエミュレートします。これらは、さまざまなブラウザの動作を細部に至るまで模倣するように設計されています。自動化スクリプトは、それらを実行するブラウザーが行うのと同じ方法で、イベントをディスパッチし、要素にフォーカスしたり、属性を処理したりします。これらはブラウザーの詳細を抽象化し、クロスブラウザーの高レベルのテスト コードを作成できるようにします。

分離されたテストの実行

TestCafe は、各テストの実行を後続のテストおよび並行して実行されるテストから分離します。

テストが完了すると、TestCafe はブラウザーの状態をリセットします。

• Cookieを削除します
• ローカルストレージとセッションストレージをクリアします
• テストされたページをリロードします

これにより、アプリの状態をリセットしたり、テストで行われた変更に対処するためのコードを記述する必要がなくなりました。その結果、テストは安定し、書き込みと読み取りが容易になり、定型コードが不要になります。

複数のテストを並行して実行すると、各テスト実行で独立したサーバー側コンテキストが取得されます。これにより、サーバー側の衝突も防止されます。

結論

TestCafe は、比類のない使いやすさと、高度な自動化および堅牢な組み込みの安定性メカニズムを組み合わせた、自己完結型のエンドツーエンド テスト ソリューションです。 TestCafe は、すべての主要なブラウザーとプラットフォームを公式にサポートしており、公式にサポートされているブラウザーを超える最新のブラウザーでも実行できるように設計されています。

how-it-works.svg

https://vasilystrelyaev.github.io/testcafe/documentation/how-it-works/