複数のiOSアプリをまたぐE2Eテストを設計する

複数のiOSアプリが連携する体験を、E2Eテストでどう検証するか。アプリ間の遷移や状態の受け渡しを含む設計上の論点を整理します。

ひとつのアプリだけを対象にしたテストでは、ユーザーが実際にたどる流れを見落とすことがあります。設計から実行まで、確認すべきポイントを順に見ていきます。

01はじめに

複数のアプリをまたぐ体験では、画面だけでなく、アプリ間の遷移やデータの受け渡しも品質に影響します。メインアプリで操作を始め、別のアプリで認証した後に元の画面へ戻る流れを考えます。

それぞれのアプリを個別に検証するだけでは、利用者が経験する一連の流れを確認できません。テストの境界をユーザーの行動に合わせて定義することが重要です。

123456func testLoginFlow() throws {
  let mainApp = XCUIApplication(bundleIdentifier: "com.example.main")
  let authApp = XCUIApplication(bundleIdentifier: "com.example.auth")
  mainApp.launch()
  mainApp.buttons["ログイン"].tap()
}

02設計の考え方

実装方法を選ぶ前に、どこからどこまでを一つの利用体験として扱うかを決めます。テストの粒度を画面単位に固定せず、利用者が達成したい結果から逆算します。

シナリオを設計するときは、次の三点をそろえます。

• アプリをまたぐ一連の操作を一つの流れとして定義する
• アプリ間で受け渡す状態と完了条件を明確にする
• 失敗時に、どの境界で止まったかを追えるようにする

03実装のポイント

複数アプリの起動と切り替えを、テストコード上でも分かる形に保ちます。操作を再利用可能な小さな単位に分けると、シナリオの意図と失敗箇所を読み取りやすくなります。

識別子や待機条件はアプリの実装とすり合わせ、画面の見た目だけに依存しないようにします。変更に強いテストにするため、動作と検証条件を明示します。XCUIApplication の使い方はAppleの公式ドキュメントにまとまっています。

04テストの安定化

E2Eテストは実行環境や通信状態の影響を受けます。待機時間を増やすだけでは不安定さの原因が見えにくくなるため、画面の準備が整ったことを判断できる条件を置きます。

確認するのは、アプリが開いたかどうかだけではありません。 期待した状態で次の操作へ進めることまで検証します。

05まとめ

アプリをまたぐE2Eテストでは、ユーザーの行動を単位にしてシナリオを設計し、遷移と状態の受け渡しを一つの流れとして検証します。観測しやすく保守しやすい形にすることで、継続的な改善に活かせます。