Alai

Anil Telaich

Apple が XCUI フレームワークを導入して以来、iOS における UI テストの自動化は、ユニットテストを書くのと同じくらい簡単になりました。 この投稿では、レイヤー デザインと結合した XCUI が、特に複数のカスタマイズされた UI 要素を持つアプリケーションを簡単に自動化するのに役立つ方法についてお話したいと思います。 このようなアプリケーションの1つであるVMware Boxerは、電子メール、カレンダー、および連絡先という3つの重要な機能を集約したVMwareのエンタープライズ・アプリケーションであり、広範囲に渡って使用されている。 VMware Boxer では、ネイティブの UITableView から高度にカスタマイズされた視覚的要素まで、複数のタイプの UI 要素を使用します。

読者が Xcode、Objective C、Swift、XCUI フレームワークおよび Apple 開発エコシステムを一般的に理解していると仮定します。 XCUI に慣れていない場合、まずここから始めるべきです。

他の UI 自動化プロジェクトと同様に、私たちのチームはどの自動化フレームワークを使用するかという疑問から始まりました。 私たちは SeeTest を使用していました。 しかし、VMware Boxer で追加された新しく複雑な機能、VMware エコシステムの製品数、およびこれらの製品間の統合テストを考えると、これは自動化戦略を見直す機会であると考えました。 以下は、私たちが検討した選択肢です：

1. SeeTest の継続

2. Earl Grey

3. XCUI

SeeTest は自動化という当面のニーズに対応する能力がありましたが、対処すべき別の課題もありました。 それは、新しいテクノロジー スタックを採用する必要があったことです。 これには、iOS 開発者の追加トレーニングと、自動化システムを保守する専任の専門家が必要です。

Appium についてはどうでしょうか。 私たちは、SeeTest について前述したのと同じ理由で、Appium を考慮しませんでした。 Appium は、ハイブリッド アプリや、Android と iOS 間で重要な共有コードがある場合に良い選択となります。

Earl Grey 1 は、Xcode と Apple 開発ツールにとどまることができ、XCTest に基づいていることから、可能な選択肢となりました。 しかし、Earl Grey 1 の自動化は、テスト対象のアプリケーションと同じプロセスで実行されます。 一方、AppleのXCUIフレームワークベースのオートメーションは、テスト対象のアプリケーションとは別のプロセスで実行されます。 テスト対象のアプリケーションは、その UI をテストするエンティティ (自動化プロセスまたはエンド ユーザー) にとってブラック ボックスに過ぎないため、これが望ましいと言えます。 テスト対象のアプリケーションは、自動化プロセスのブラック ボックス以外の何者でもないはずです。

Apple のエコシステム内の新しいツールで、Apple のアプローチと一致していないもの (たとえば Earl Grey 1) は、警告なしに失敗する可能性があります。 そのようなアプローチは、Apple からの新しいまたは将来の提供品で動作し続けるために、メンテナンスに多くの労力を必要とするかもしれません。

Early Grey 2 では、XCUI と対話する機能を追加しました。 これは XCUI と連携する試みでしたが、これらの既知の問題がありました。 これにより、開発者は自動化に対してより多くのコントロールを持つことができ、Apple のエコシステムにおけるあらゆる革新の直接的な受益者となります。

• App under test and XCUI automation module
• Accessibility Identifiers
• テスト クラス
• フロー クラス
• まとめ

App under test and XCUI automation module

詳細に入る前に、XCUI を使用する自動化モジュールはテスト対象のアプリケーションから独立したプロセスとして実行されるということを再確認しておくことが重要です。 手始めに、これから Automation Module(AM) と呼ぶ、新しいモジュールを追加しました。 AM は、XCUI を使用した VMware Boxer の自動化に使用するクラスとデータ構造のコレクションを含むワークスペースです。

Accessibility Identifiers

アプリケーションは、テスト可能性を考慮して開発することが重要です。 開発者の責任の 1 つは、エンド ユーザーに公開される各ユーザー インターフェース要素に、開発中にアクセシビリティ識別子が設定されていることを確認することです。 アクセシビリティ識別子は、テスト中のアプリケーションと XCUI 自動化プロセスとの間のリンクです。

アクセシビリティ識別子は、テスト中のアプリケーションと XCUI 自動化プロセスとの間のリンクです。 使用するデザイン パターンの選択は、テストが簡単に実装でき、維持しやすく、再利用可能で、堅牢で、拡張可能であるべきであることを念頭に置いて、たどり着きました。 以下のコンテンツでは、VMware Boxer 用の XCUI オートメーション モジュールのアーキテクチャーの層について説明します：

次の図は、基本的な構成要素を示しています。

テスト クラス

これは、テスト メソッドを持つクラスを持っている層です。 この層の意図は、テストされるものだけを記述する最小限のコードで構成されるテストを持つことです。 また、テストを実装する開発者は、テストされるものをテストするために必要な高レベルのアプリケーション フローについてだけ考える必要があります。 残りの複雑な部分（例えば、必要なテストを実行するための UI への移動方法）は、再利用可能なレイヤに抽象化する必要があります。 下の画像は、上記の意図を説明するテストメソッドの例です。このコードは、設定 UI が機能の有効化/無効化を助けることができるかどうか、または必要なスイッチコントロールがあるかどうかをテストします。

したがって、テストを書いている開発者は疑似コードのようにシンプルなコードを書くことができました。

フロー クラス

フローは、さまざまなテスト クラスに必要な機能を提供するクラスのコレクションを表します。 機能には、実際のテストケースを実行する前にアプリをセットアップすることや、テスト中のアプリの特定の部分に移動することが含まれるかもしれません。 これらの機能のほとんどは再利用可能で、複数のテストで必要とされます。例えば、上記のサンプルテストケースでは、1.アプリを起動すること、2.アプリを起動することが要求されます。 Feature Controller の設定画面に移動する。

したがって、フロー クラスはテストから呼び出され、「設定に移動する」または「Feature Controller の設定に移動する」のようなフローを実装することになります。 ビューコントローラは、高レベルで、（バックビューで） UIControls とそれらの UIControls とのユーザーの相互作用に応答するメソッドを持つクラスとして見ることができます。 Screen クラスは、単に View Controller のプロキシマッピングです。 下図は、このマッピングを示しています。 UIの中にInitial Viewというセルがあり、ユーザーがこのセルをタップすると、アプリの初期ビューとしてマークされるべきものを選択することができます。

この画面クラスの疑似コードは、次のようになります –

// The class models the SettingFormViewController for XCUI tests.public class SettingsFormScreen { 
private static let navBarId = "Boxer.Settings.NavigationBar"
private lazy var featureControllerCell = boxerApp.application.tables.cells public func navigateToFeatureController() -> Bool {
return // tap on Cell with featureControllerCellId
}
}class AccessibilityIdentifiers: NSObject {// MARK: Settings Screenstatic let featureControllerCellId = "Boxer.Settings.FeatureControllerCell"
}

上のコードで boxerApp とは何ですか。 BoxerApp は、テスト対象のアプリケーションとその画面をカプセル化した BoxerApp クラスのインスタンスで、上記のコードではユニットを表します。 これは次のセクションで説明します。

上記のコードは、VMware Boxer の SettingFormViewController をモデル化しています。 クラスの命名規則として、名前はビュー コントローラーの名前から、ViewController という接尾語を Screen に置き換えて派生しています。 また、アクセシビリティ識別子を持つ便利なクラスにも注意してください。

アクセシビリティ識別子は、テスト対象のアプリケーションと XCUI 自動化プロセスとの間の共通のリンクです。 VMware Boxer XCUI オートメーション モジュール

UITest モジュールは、実行中のアプリケーションをテストします。 テスト対象のアプリケーションの 1 つのインスタンスが 1 つのユニットであるように、アプリケーション モデルを設計することが重要です。 つまり、テスト対象のアプリケーションは、テストの要件に基づいてテスト（クラスのコレクション）から呼び出されるビジネスフロー（フロークラスのコレクション）に参加するスクリーンクラスのコレクションと見なす必要があります。 各アプリケーション ユニットには、1 つのビュー コントローラーに対応する各スクリーン クラスのインスタンスが正確に 1 つあるべきです。

これをどのように実現するか。 下図は、このカプセル化について説明しています。

したがって、XCUITest スイートが起動する前に、最初に行うことは、テスト中のアプリケーションのバンドル識別子を使用して BoxerApp モジュールのインスタンスを生成することです。 下図を参照してください。

BoxerApp (XCUIApplication と Screens をカプセル化したユニット)のこのインスタンスは Tests::testMethod から Flows::flowMethod に最初のパラメーターとして渡されています。

Flows::flowMethod は今度は Screen::screenMethod に呼び出し、必要ならBoxerApp に渡します。

最終的にアプリケーションUIとの対話はScreen::screenMethodを通して行われます。

下図は上記の設計を表しています。

まとめ

XCUI のテストを書くことは、計画を立ててやらないと面倒でどうにもならないことがある。 この投稿が、自動化プロジェクトをモジュラー、クリーン、レイヤー方式で構成することを考える方法について、役に立つポインターを提供することを願っています。

XCUI : パート 2 – クリーンな方法でネイティブ アプリケーションと対話する

XCUI : パート 3 – クリーンな方法で XCUI ランタイムがテスト中のアプリケーションと対話する方法。

XCUI : 第 4 部 – システム アラートの処理

XCUI : 第 5 部 – テスト進捗状況の監視とレポートへのアクセスおよびスクリーンショットのキャプチャ

XCUI : 第 4 部 – システム アラートの処理

XCUI : 第 4 部 – テスト進捗状況の監視とレポートへのアクセスおよびスクリーンショットのキャプチャ