コンテキストの管理
多くのアプリプラットフォームに共通する機能として、開発者がプラットフォームネイティブのアプリフレーム内にWebコンテンツを埋め込むことができるというものがあります。これにより、開発者はWeb技術や既存のWebコンテンツをアプリ機能の一部または全部に活用することができます。しかし、単一のアプリケーション内で「モード」を混在させることの複雑さが増すため、「ネイティブ」の要素と動作をターゲットとするように設計された自動化ツールにとっては困難が生じることがあります。
Appiumは、「コンテキスト」と呼ばれる異なるアプリモードを操作するための一連のAPIを提供しており、Appiumドライバーはこれらの異なるモードでの自動化コマンドをサポートする場合に実装できます。Appiumは、この目的のためにW3C WebDriver仕様に3つの基本コマンドを追加しました。
コマンド名 | メソッド/ルート | パラメータ | 説明 | 戻り値 |
---|---|---|---|---|
コンテキストの取得 |
GET /session/:id/contexts |
利用可能なコンテキストのリストを取得します。 | array<string> |
|
現在のコンテキストの取得 |
GET /session/:id/context |
アクティブなコンテキストの名前を取得します。 | string |
|
コンテキストの設定 |
POST /session/:id/context |
name (string ) |
指定されたname を持つコンテキストに切り替えます。 |
null |
このAPIは、ドライバー側でのさまざまな意味解釈を処理できるだけの柔軟性を備えています。たとえば、XCUITestドライバーには、ネイティブアプリコンテキストとアクティブなwebviewの2種類のコンテキストが含まれており、webviewごとに1つのコンテキストとなります。 Get Contexts
を呼び出すと、名前のリストが返されます。テスト作成者は、このリストを調べて、適切なコンテキストに切り替えるために使用できます。別の例として、Appium Altunity Pluginは、UNITY
コンテキストの概念を導入しています。これは、UNITY
コンテキストの外部にいるときは、アクティブなドライバーの通常のコマンド実装が使用されるように、プラグイン固有のすべての動作をカプセル化します。
Get Contexts
の呼び出しには、常に少なくとも1つのコンテキストが含まれていることに注意することが重要です。慣例的に、必ずしもNATIVE_APP
という名前ではありません。これはデフォルトのアクティブなコンテキストです。
現在使用しているコンテキストの種類によっては、ドライバーの動作が変わる場合があります。XCUITestドライバーは、webviewコンテキストをターゲットにしている場合、要素を見つけて操作するための通常のルーチンを実行しません。代わりに、Web要素に適した別のルーチンセットを実行します。これにより、さまざまな結果が生じる可能性があり、たとえば、異なるロケータ戦略のセットがサポートされる場合があります。
上記の表のコマンド名は、コマンドの一般的な参照であり、コード例ではありません。言語固有のクライアントライブラリでContext APIにアクセスする方法の例については、特定のライブラリのドキュメントを参照してください。