コンポーネントテスト
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テストを実行するインスタンスでホストされている正しいサーバーインスタンスを開くことが保証されます。
例
人気のあるコンポーネントフレームワークを使用したコンポーネントテストの様々な例は、サンプルリポジトリで見つけることがで きます。