次の方法で共有

セルフホステッド開発者ポータルをテストする

適用対象: Developer | Basic | Basic v2 | Standard | Standard v2 | Premium | Premium v2

この記事では、セルフホステッド ポータルの単体テストとエンド ツー エンドのテストを設定する方法について説明します。

単体テストを作成する

単体テストは、小規模な機能を検証するためのアプローチです。 単体テストは、アプリケーションの他の部分から分離して動作します。

サンプル シナリオ

このシナリオでは、パスワード入力コントロールをテストします。 少なくとも次のものを含むパスワードのみを受け入れます。

  • 1 つの文字
  • 1 つの数値
  • 1 つの特殊文字

これらの要件を検証するテストは次のようになります。

const passwordInput = new PasswordInput();

passwordInput.value = "";
expect(passwordInput.isValid).to.equal(false);

passwordInput.value = "password";
expect(passwordInput.isValid).to.equal(false);

passwordInput.value = "p@ssw0rd";
expect(passwordInput.isValid).to.equal(true);

プロジェクト構造

検証するコンポーネントの横に単体テストを保持するのが一般的です。

component.ts
component.spec.ts

HTTP 要求の模擬テストを実行する

コンポーネントで HTTP 要求が行われることが予想される場合もあります。 コンポーネントは、さまざまな種類の応答に適切に対応する必要があります。 特定の HTTP 応答をシミュレートするには、MockHttpClient を使用します。 これは、プロジェクトの他の多くのコンポーネントで使用される HttpClient インターフェイスを実装します。

const httpClient = new MockHttpClient();

httpClient.mock()
    .get("/users/jane")
    .reply(200, {
        firstName: "Jane",
        lastName: "Doe"
    });

エンドツーエンド テストを作成する

エンド ツー エンドのテストでは、ユーザーが実行すると予想される正確な手順を実行する特定のユーザー シナリオを実行します。Azure API Management 開発者ポータルのような Web アプリケーションでは、ユーザーはコンテンツをスクロールし、特定の結果を得るためにオプションを選択します。

ユーザーの移動を複製するには、Puppeteer のようなブラウザー操作ヘルパー ライブラリを使用します。 これにより、ユーザーの操作をシミュレートし、想定されるシナリオを自動化できます。 さらに Puppeteer では、テストのあらゆる段階でのページまたはコンポーネントのスクリーンショットを自動的に取得します。 これらを後で前の結果と比較して、差異や不具合の可能性を検出します。

サンプル シナリオ

このシナリオでは、ユーザーのサインイン フローを検証する必要があります。 このシナリオでは次の手順が必要です。

  1. ブラウザーを開き、サインイン ページに移動します。
  2. メール アドレスを入力します。
  3. パスワードを入力します。
  4. [サインイン] を選択します。
  5. ユーザーがホーム ページにリダイレクトされたことを確認します。
  6. ページに [プロファイル] メニュー項目が表示されていることを確認します。 これは、正常にサインインしたことの指標の 1 つです。

テストを自動的に実行するには、まったく同じ手順でスクリプトを作成します。

// 1. Open browser and navigate to the sign-in page.
const page = await browser.newPage();
await page.goto("https://contoso.com/signin");

// 2. Enter email.
await this.page.type("#email", "john.doe@contoso.com");

// 3. Enter password.
await this.page.type("#password", "p@s$w0rd");

// 4. Click Sign-in.
await this.page.click("#signin");

// 5. Verify that user got redirected to Home page.
expect(page.url()).to.equal("https://contoso.com");

// 6. Verify that the page includes the Profile menu item.
const profileMenuItem = await this.page.$("#profile");
expect(profileMenuItem).not.equals(null);

Note

#email、#password、#signinなどの文字列は、ページ上の HTML 要素を識別する CSS に似たセレクターです。 詳細については、 セレクター レベル 3 W3C 仕様を参照してください。

UI コンポーネント マップ

ユーザー フローでは多くの場合、同じページまたはコンポーネントを経由します。 良い例は、すべてのページに存在するメインの Web サイト メニューです。

同じセレクターが毎回のテストで構成および更新されないようにするために、UI コンポーネント マップを作成します。 たとえば、前の例の手順 2 から 6 を、次のわずか 2 行に置き換えることができます。

const signInWidget = new SigninBasicWidget(page);
await signInWidget.signInWithBasic({ email: "...", password: "..." });

テスト構成

特定のシナリオでは、事前に作成されたデータまたは構成が必要です。 たとえば、ソーシャル メディア アカウントを使用してユーザーのサインインを自動化する必要がある場合があります。 このデータをすばやく簡単に作成することは困難です。

このため、テスト シナリオに特別な構成ファイルを追加することができます。 テスト スクリプトによって、このファイルから必要なデータを取得できます。 ビルドおよびテストのパイプラインに応じて、テストでは名前が指定されたセキュリティで保護されたストアからシークレットをプルできます。

プロジェクトの src フォルダーに格納される validate.config.json の例を次に示します。

{
    "environment": "validation",
    "urls": {
        "home": "https://contoso.com",
        "signin": "https://contoso.com/signin",
        "signup": "https://contoso.com/signup/"
    },
    "signin": {
        "firstName": "John",
        "lastName": "Doe",
        "credentials": {
            "basic": {
                "email": "johndoe@contoso.com",
                "password": "< password >"
            },
            "aadB2C": {
                "email": "johndoe@contoso.com",
                "password": "< password >"
            }
        }
    },
    "signup": {
        "firstName": "John",
        "lastName": "Doe",
        "credentials": {
            "basic": {
                "email": "johndoe@contoso.com",
                "password": "< password >"
            }
        }
    }
}

ヘッドレスと通常のテストの比較

Chrome や Microsoft Edge などの最新のブラウザーでは、ヘッドレス モードと通常モードの両方で自動化を実行できます。 ヘッドレス モードでは、ブラウザーはグラフィカル ユーザー インターフェイスを使用せずに動作します。 それでもなお、同じページとドキュメント オブジェクト モデル (DOM) の操作を実行します。 ブラウザー UI はデリバリー パイプラインには通常必要ありません。 その場合、ヘッドレス モードでテストを実行する方が優れたオプションです。

テスト スクリプトを開発するときは、ブラウザーで何が起こっているかを実際に確認すると便利です。 このときは、通常モードを使用することをお勧めします。

モードを切り替えるには、constants.ts ファイルの headless オプションを変更します。 これはプロジェクトの tests フォルダーにあります。

export const LaunchOptions = {
    headless: false
};

もう 1 つの便利なオプションは slowMo です。 これはそれぞれのアクション間でテストの実行を一時停止します。

export const LaunchOptions = {
    slowMo: 200 // milliseconds
};

テストの実行

このプロジェクトでテストを実行するには、次の 2 つの組み込み方法があります。

npm コマンド

npm run test

テスト エクスプローラー

VS Code 用のテスト エクスプローラー拡張機能を使用します。 たとえば、 Mocha テスト エクスプローラー には便利な UI と、ソース コードの変更ごとにテストを自動的に実行するオプションがあります。

Visual Studio Code テスト エクスプローラーのスクリーンショット

関連コンテンツ

開発者ポータルの詳細については、次を参照してください。

  • Last updated on