コンポーネントテスト
WebdriverIOのブラウザランナーを使用すると、WebdriverIOとWebDriverプロトコルを使って、実際のデスクトップまたはモバイルブラウザ内でテストを実行し、ページにレンダリングされる内容を自動化して操作することができます。このアプローチは、JSDOMに対してのみテストを許可する他のテストフレームワークと比較して、多くの利点があります。
どのように機能するのか?
ブラウザランナーはViteを使用してテストページをレンダリングし、ブラウザでテストを実行するためのテストフレームワークを初期化します。現在はMochaのみをサポートしていますが、JasmineとCucumberはロードマップ上にあります。これにより、Viteを使用していないプロジェクトであっても、あらゆる種類のコンポーネントをテストすることができます。
ViteサーバーはWebdriverIOテストランナーによって起動され、通常のe2eテストで使用していたすべてのレポーターとサービスを使用できるように構成されています。さらに、ページ上の任意の要素と対話するためのWebdriverIO APIのサブセットにアクセスできるbrowser
インスタンスを初期化します。e2eテストと同様に、グローバルスコープにアタッチされたbrowser
変数を通じて、またはinjectGlobals
の設定に応じて@wdio/globals
からインポートしてそのインスタンスにアクセスできます。
WebdriverIOは以下のフレームワークに対する組み込みサポートを提供しています:
- Nuxt: WebdriverIOのテストランナーはNuxtアプリケーションを検出し、プロジェクトのコンポーザブルを自動的にセットアップし、Nuxtバックエンドのモック化をサポートします。詳細はNuxtのドキュメントを参照してください。
- TailwindCSS: WebdriverIOのテストランナーはTailwindCSSを使用しているかを検出し、環境を適切にテストページに読み込みます。
セットアップ
ブラウザでのユニットテストまたはコンポーネントテスト用にWebdriverIOをセットアップするには、以下のコマンドで新しいWebdriverIOプロジェクトを初期化します:
npm init wdio@latest ./
# または
yarn create wdio ./
設定ウィザードが起動したら、ユニットテストとコンポーネントテストを実行するためのbrowser
を選択し、必要に応じていずれかのプリセットを選択するか、基本的なユニットテストのみを実行したい場合は「Other」を選択します。プロジェクトですでにViteを使用している場合は、カスタムVite設定を構成することもできます。詳細については、すべてのランナーオプションをご確認ください。
注意: WebdriverIOはデフォルトでCIヘッドレスでブラウザテストを実行します(例:CI
環境変数が'1'
または'true'
に設定されている場合)。この動作はランナーのheadless
オプションを使用して手動で構成できます。
このプロセスの最後に、runner
プロパティを含むWebdriverIOの様々な設定を含むwdio.conf.js
が作成されるはずです:
loading...
異なるcapabilitiesを定義することで、必要に応じて異なるブラウザで並行してテストを実行できます。
すべての仕組みについてまだ不明な点がある場合は、WebdriverIOでのコンポーネントテストを始めるための以下のチュートリアルをご覧ください:
テストハーネス
テストで何を実行し、コンポーネントをどのようにレンダリングするかは完全にあなた次第です。ただし、ユーティリティフレームワークとしてTesting Libraryを使用することをお勧めします。これはReact、Preact、SvelteおよびVueなど様々なコンポーネントフレームワーク用のプラグインを提供しています。テストページにコンポーネントをレンダリングするのに非常に便利であり、テストごとにこれらのコンポーネントを自動的にクリーンアップします。
Testing Libraryのプリミティブ機能とWebdriverIOコマンドを自由に組み合わせることができます:
loading...
注意: Testing Libraryのレンダーメソッドを使用すると、テスト間で作成されたコンポーネントが削除されます。Testing Libraryを使用しない場合は、テスト間でクリーンアップされるコンテナにテストコンポーネントをアタッチするようにしてください。
セットアップスクリプト
Node.jsまたはブラウザで任意のスクリプトを実行してテストをセットアップできます。例えば、スタイルの注入、ブラウザAPIのモック化、またはサードパーティサービスへの接続などです。WebdriverIOのフックはNode.jsでコードを実行するために使用でき、mochaOpts.require
はテストが読み込まれる前にブラウザにスクリプトをインポートすることができます:
export const config = {
// ...
mochaOpts: {
ui: 'tdd',
// ブラウザで実行するセットアップスクリプトを提供する
require: './__fixtures__/setup.js'
},
before: () => {
// Node.jsでテスト環境をセットアップする
}
// ...
}
例えば、テスト内のすべてのfetch()
呼び出しを次のようなセットアップスクリプトでモックする場合:
import { fn } from '@wdio/browser-runner'
// すべてのテストが読み込まれる前にコードを実行
window.fetch = fn()
export const mochaGlobalSetup = () => {
// テストファイルが読み込まれた後にコードを実行
}
export const mochaGlobalTeardown = () => {
// specファイルが実行された後にコードを実行
}
これで、テスト内ですべてのブラウザリクエストにカスタムレスポンス値を提供できます。グローバルフィクスチャについての詳細はMochaのドキュメントをご覧ください。
テストとアプリケーションファイルの監視
ブラウザテストをデバッグする方法はいくつかあります。最も簡単な方法は、WebdriverIOテストランナーを--watch
フラグ付きで起動することです:
$ npx wdio run ./wdio.conf.js --watch
これによりすべてのテストが最初に実行され、すべてが実行されると停止します。その後、個々のファイルに変更を加えると、それらが個別に再実行されます。アプリケーションファイルを指すfilesToWatch
を設定すると、アプリに変更が加えられたときにすべてのテストが再実行されます。
デバッグ
IDEでブレークポイントを設定し、それがリモートブラウザによって認識されるようにすることは(まだ)できませんが、debug
コマンドを使用して任意の時点でテストを停止することができます。これによりDevToolsを開き、sourcesタブでブレークポイントを設定してテストをデバッグできます。
debug
コマンドが呼び出されると、ターミナルにNode.js replインターフェースが表示され、次のように表示されます:
The execution has stopped!
You can now go into the browser or use the command line as REPL
(To exit, press ^C again or type .exit)
Ctrl
またはCommand
+ c
を押すか、.exit
と入力してテストを続行します。
Selenium Gridを使用して実行する
Selenium Gridをセットアップしてそのグリッドを通じてブラウザを実行している場合は、テストファイルが提供されている正しいホストにブラウザがアクセスできるように、host
ブラウザランナーオプションを設定する必要があります:
export const config: WebdriverIO.Config = {
runner: ['browser', {
// WebdriverIOプロセスを実行するマシンのネットワークIP
host: 'http://172.168.0.2'
}]
}
これにより、ブラウザがWebdriverIOテストを実行するインスタンスでホストされている正しいサーバーインスタンスを開くことが保証されます。
例
人気のあるコンポーネントフレームワークを使用したコンポーネントテストの様々な例は、サンプルリポジトリで見つけることができます。