AppIntentsTestingによるApp Intentの利用状況の検証

こんにちは。私はVenkateshです。 App Intentチームのソフトウェアエンジニアです。 本日は、App Intentの テスト方法をご紹介します。

AppIntentsTestingという 全く新しいフレームワークを使って。 App Intentフレームワークは 中核的な部分を担っており、 アプリをシステムと 統合させるものです。 毎年、より多くの体験を 支えています。例えば、 App Intentにより、ユーザーはSiriを使って アプリを操作できるようになります。 ショートカットアプリを使って 強力な自動化を構築することも可能です。

Spotlightはそれを使って、システム全体の 検索にアプリのコンテンツを表示します。 ウィジェットはそれを使って ホーム画面にデータを表示します。

AppIntentが初めての方は、 WWDC25のこのトークをご覧ください。 新しい進歩について 学びたい方は、 WWDC26のこのトークをご覧ください。 App Intentが非常に多くの体験を 支えているため、 すべてのインテント、エンティティ、 クエリが正しく動作する必要があります。 AppIntentsTestingは全く新しい フレームワークで、 それらすべて、そしてそれ以上のことを テストできます。 本日カバーする内容は以下の通りです。 まず、サンプルアプリを紹介し、 最初のテストの書き方を お見せします。 次に、AppIntentsTestingが テストを実行する仕組みを見ていきます。

その後、エンティティクエリのテストで レベルアップし、 複数のインテントを 組み合わせます。

最後に、App Intentの いくつかの部分をテストします。 アプリを超えた領域：SpotlightとView アノテーション

それでは早速始めて、 いかに簡単かをお見せします。 AppIntentsTestingの 始め方を。 これはCometCal、サンプルカレンダーアプリです。

SwiftUIアプリで、カレンダー、 イベント、 参加者を管理し、App Intentに 完全に統合されています。 同僚のJustinと私は それに取り組んでいます。 宇宙探検家のクルーが ミッションを管理しやすくするために。 このセッションでは、 テスト方法を学びます。 AppIntentsTestingを使って。

CometCalをSiriで使えるように した方法については、 彼のコードアロングをご覧ください。

まず、Create Calendarフローを 実行するシンプルなテストを書きます。

AppIntentsTestingを始めるのに 必要なのは、 UI Testingバンドルだけです。 まだ持っていないので、 作成しましょう。

わかりやすい名前を付けましょう。 次に、開発チームを選択します。 AppIntentsTestingには、テストランナーと アプリが必要です。 コード署名に同じ開発チームを 使用するため、 ここで正しいチームを 選択してください。 次に、Bundle Identifierを 入力します。

そして正しいターゲットを 選択します。 「Finish」をクリックします。

これでUI Testingバンドルが 作成されます。 インテント実行に関連するすべての テスト用に新しいファイルを作成します。

素晴らしい、テストを 書き始める準備ができました。

テストするインテントに 移動しましょう。

CreateCalendarは、名前と色で 新しいカレンダーを作成します。

まず、AppIntentsTestingフレームワークを インポートする必要があります。

標準のXCTestCaseから始め、 テストメソッドを作成します。

IntentDefinitionsオブジェクトを作成して テストフローを開始します。

IntentDefinitionsはCometCalの Bundle Identifierを受け取り、 すべてのインテント、エンティティ、 アプリが定義するクエリへのアクセスを アプリをインポートせずに提供します。 特定のインテントの定義に アクセスするには、 intentsプロパティを使用し、 インテント名をサブスクリプトとして 渡します。

これによりIntentDefinitionオブジェクトが 返されます。 makeIntentを呼び出して、インテントの populated instanceを作成できます。

インテントが期待する 任意のパラメータを渡せます。

ここでCreateCalendarIntentは 名前と色を受け取ります。 私は人類にとって重要な ミッションを担っており、 クルーと私がこのミッションを 遂行できるよう、わかりやすい名前が必要です。

「Occupy Saturn」と呼びましょう。 そして色を付けます。 赤にします。

ここで、colorはAppEnumです。 AppEnumのraw string valueを 渡すだけで、 フレームワークが正しい型に 変換します。 テストコードは アプリに対してビルドされないため、 パラメータ名と型は オートコンプリートを提供しません。 インテントパラメータに基づいて 正しく入力する必要があります。 この型変換はほとんどのパラメータ型で すぐに使えます。 ただし、独自のカスタム型を 渡したい場合は、 ドキュメントでIntentValueConvertibleWrapperを 調べてください。 インテントを作成したので、 .run()メソッドを呼び出して アプリ内で実行します。

インテントのperformメソッドから 戻り値が必要な場合、 runメソッドの結果を キャプチャして、 valueプロパティで取得できます。

ここでCreateCalendarIntentは CalendarEntityとして新しいカレンダーを返します。

これがCalendarEntityです。

確認できるtitleプロパティが あります。

新しいイベントに正しいタイトルが あることを確認したい場合、

まずresult.valueを使って 新しいカレンダーにアクセスし、 必要なプロパティ名を チェーンするだけです。 これはdynamic member lookupを使って 新しいカレンダーからタイトルを取得します。

このテストを実行する準備ができました。 実行する前に、 スマートフォンに切り替えて、 現在どのカレンダーが あるか確認しましょう。

アプリには現在3つのカレンダーがあります： Deep Space、Mission Control、 そしてStargazing。 テストを実行した後、 Occupy Saturnカレンダーが リストに追加されると期待します。

Xcodeに戻って、 このテストを実行しましょう。

テストが成功しました。

スマートフォンで新しいカレンダーが 存在することを確認しましょう。 はい、テストにより Occupy Saturnカレンダーが作成されました。 赤色で。

たった5行のコードで、 テストを使ってオンデバイスの App Intentを実行しました。 AppIntentsTestingの動作を 確認したので、 より詳しく説明します。

AppIntentsTestingはApp Intentの 統合テストフレームワークです。 UIテストと同様に、文字列を使って インテントを検索します。 アプリの内部へのアクセスは 一切不要です。

テストは標準のXCUITestバンドルに 存在し、 独自のプロセスで 実行されます。 アプリは別プロセスで実行され、 App IntentをオンデバイスでExcecuteします。

テストランナーはプロセス境界を越えて App Intentを実行します。 状態を共有せずに 実行結果を受け取ります。

AppIntentsTestingが開発者にとって 意味することを説明します。 テストはApp Intentの フルスタックを通じて実行されます。 ユーザーが使うのと 同じコードパスです。 モックなし、スタブなし。

XCUITestバンドルを作成するか、 既存のXCUIテストに追加します。 Continuous Integrationパイプラインが 自動的に取り込みます。 アプリコードは好きな方法で 構成できます。 テストターゲットはアプリケーションの コードをインポートしません。 渡すのはBundle Identifierのみです。

つまり、アプリコードを テストターゲットにコンパイルする必要はありません。

これらすべてにより、リリース間で 安定したテストが得られます。 UIに依存しません。 アプリのUIにも、システムのUIにも。

概要を踏まえて、 より複雑なテストに進みましょう。

アプリのアクション、データ、クエリは App Intentsインテグレーションの 構成要素です。 ショートカット、Siriインタラクション、 Spotlight検索を支えています。 このコードがリグレッションすると、 しばしば ユーザーが予期しない システム動作を経験することになります。

エンティティが検索されるとき、 ショートカット内、Siri経由、 またはApp Intentがエンティティを 表示する他の場所でも、 エンティティクエリが正しい結果を 返す責任があります。 AppIntentsTestingは文字列クエリの その動作を確認するのに役立ちます。 識別子ルックアップと サジェストされたエンティティも。 状況を説明します。 コズミックレイという ほぼ無害なデバイスがあります。 残念な出来事により、 「Cosmic Ray Calibration」イベントの 名前を 「Cosmic Ray Rebuilding」に 変更する必要があります。 これが頻繁に発生しているので、 ショートカットを作成すべきでしょう。

イベントはすでにアプリに 存在しています。 ショートカットアプリを 開きます。 ショートカットに移動して、 イベントを検索します。

最初は候補イベントの 一覧が表示されます。 他のイベントを 検索したい場合、 検索バーを使用できます。これにより EventEntityの文字列クエリが呼ばれて 結果が決定されます。

「利用可能なオプションなし」と表示されます。 文字列クエリはまだ実装されていません。 AppIntentsTestingを使って テスト駆動アプローチで実装します。

テストはこちらです。 エンティティとインテントの 定義を作成することから始めます。

アプリに既知のイベントセットが 含まれていることを確認するため、 SeedSampleEventsIntentを 実行します。 これはアプリデータをリセットして イベントを追加します。 すぐに戻ってきます。 理想的には、EntityとIntent定義を テスト関数の外に移して 他のテストで再利用できるようにし、 データのシーディングを setUpメソッドに移します。 そうしましょう。 以降は、 テスト機能に専念します。

更新されたテストです。 エンティティ文字列クエリを呼び出します。 Eventエンティティ定義の entities(matching:)メソッドを使って。 これはオンデバイスで 文字列クエリを実行します。 このメソッドはEventEntity表現の 配列を返します。 カウントをアサートできます。

インテントと同様に、 dynamic member lookupを使えます。 任意のエンティティプロパティの 値を取得するために。 ここではイベントのタイトルを 取得しています。 クエリが正しく動作することを 確認するためにアサートします。 テストを実行します。 予想通り失敗しました。 失敗により、何を作る必要があるかが 正確にわかります。

EventEntityQueryに 移動します。 現在、識別子でイベントを 返すことができます。 そしてサジェストされたイベントを 返すことができます。 しかし、EntityStringQueryの 機能がありません。 追加しましょう。

EntityStringQuery適合を 追加します。

entities(matching:)メソッドを 実装します。 タイトルでイベントをフィルタリングして、 マッチしたEventEntitiesを返します。

テストに戻って実行すると、 パスします。 エンティティ文字列クエリが 期待通りに動作することを確認しました。

デバイスで変更を確認します。 まず、イベントが存在することを 確認します。 次に、ショートカットアプリに 移動します。 ショートカットを開き、 同じイベントをもう一度検索します。 今度はイベントが見つかりました。

最初にテストを書き、 次に通過させるためにフィーチャーを作りました。 それがAppIntentsTestingでの テスト駆動開発です。 さあ、Cosmic Rayを再構築する時間です！

レベルアップして、 1つのテストで複数のインテントを組み合わせましょう。 複雑なショートカットを構築するには、 インテントの結果を取得して、 別のインテントのパラメータとして渡すことがよくあります。 このフローは多くの便利な 自動化の基盤を形成します。

状況はこうです。 チームのための 練習セッションを設定していました。 Asteroid Dodgeballを うまくなるために。 ただし、チームメンバーの一人が 新しかったため、 イベントの目的をルールの説明に 変更することにしました。 これはアプリのコアワークフローなので、 シミュレートするテストを書きたいです。

このテストは前の例を 基にしています。 説明します。

必要なパラメータで CreateEventIntentを実行することから始めます。 前の例でmakeIntentが型変換を どう処理するかを説明しました。

最初の3つのパラメータは すべてプリミティブ型です。

最後のパラメータが より興味深いです。 calendarパラメータは CalendarEntityを受け取ります。 ただし、文字列を 渡すだけです。 App Intentランタイムは自動的に EntityStringQueryを呼び出します。 CalendarEntityに関連付けられたものを 呼び出して最初のマッチした値を入力します。

イベントを作成した後、 タイトルを確認します。

次に、UpdateEventIntentを 実行します。 これはイベントと、加えたい 更新を受け取ります。 タイトルのみを更新しているので、 それを渡します。 更新するイベントには、 直接送ることができます。 元のrunメソッドからの EventEntityを。 これはショートカットでインテントを 組み合わせる方法を反映しています。

最後に、イベントに 更新されたタイトルがあることをアサートします。

今回、テストセットアップ中に アプリを起動しています。 正しく動作していることを 確認するために。 テストを実行する時間です。 アプリが起動し、

イベントが作成され、

そして更新されます。

成功！ エンティティの作成、チェーン、 更新、アサーション。 すべてデバイス上で、 1つのテストで。 さて、Asteroid Dodgeballの ルールブックはどこに置いたかな… AppIntentsTestingのテストは軽量で、 高速で、毎コミットで実行できます。

テスト結果を信頼できるものにするには、 各テストが自己完結している必要があります。 テスト専用インテントがそれを 助けます。

テスト専用インテントはシンプルで、 テストを助けるためだけに 存在するフォーカスされたインテントです。 テスト機能を 改善するために使用できます。 テストが必要なデータを 正確に作成できます。 以前の実行からの残留データが 不安定な結果を引き起こしません。

UIナビゲーションなしで アプリの任意のビューに直接ジャンプできます。 画面を再設計しても、 これらのテストは動作し続けます。 そして、より広い考え方はこうです。 テスト専用インテントはアプリの あらゆる機能をラップできます。 App Intentをまだ採用していない ものでも。 内部ナビゲーション、データ管理、 状態操作。テスト専用インテントで ラップすれば、 AppIntentsTestingを通じて テストできます。 CometCalのソースコードには 複数のテスト専用インテントが含まれています。 一例として、先ほどの文字列クエリテストの SeedSampleEventsIntentがあります。 カレンダーに既知のイベントセットを 作成します。 任意のインテントをテスト専用インテントに する方法を説明します。

isDiscoverable: falseでマークします。 これにより、システムが他の場所で 公開するのを防ぎます。

そして#if DEBUGコンパイラディレクティブで ラップします。 テストだけがこのインテントに アクセスできるように。

ここまで、App Intentを 単独でテストする方法を学びました。 しかし本当のパワーは、 App Intentが 機能をシステム全体にわたって ユーザーに届ける方法にあります。 アプリの外でアプリの機能を 使えるように。 次に、これらのシステムレベルの 統合をテストする方法を示します。

Spotlightにより、ユーザーは1か所から システム全体を検索できます。 エンティティをインデックスすると、 それらが検索結果に表示されます。 アプリを先に開かなくても アプリのコンテンツを見つけられます。 CometCalがイベントを作成すると、 Spotlightにエンティティをインデックスするべきです。 しかし、ある時、緊急の通信を受けました。 フリートコマンダーから Dark Matter Symposiumがいつか聞かれました。

ナノ秒が貴重であることはわかっています。 だからSpotlightを使って この情報を得たかったのです。 すぐに返信するために。 しかし、Spotlight検索では 何も見つかりませんでした。 ダークマターに関するこの情報は 興味深いですが、 探しているものではありません！ アプリを開くと、 イベントは確かに存在していました。 すぐに詳細を送り、 デバッグ作業に取り掛かりました。

イベント作成コードに移動して デバッグしました。 バグはシンプルです。開発中に インデックスコードをコメントアウトして、 再度有効にするのを忘れていました。 アプリの動作は変わらなかったため、 バグは検出されませんでした。

修正はシンプルです。 インデックス呼び出しの コメントを外すだけです。

しかし、これが再び起きないように するにはどうすれば？ バグを見つけるためではなく、 リグレッションを防ぐためのテストを書けます。

spotlightQuery()メソッドを使って 始めます。 Spotlightと通信するために。 このメソッドは文字列を受け取り、 それにマッチするSpotlightインデックス済み EventEntity表現のリストを返します。 最初、イベントは存在しないので、 spotlightQuery()が結果を 返さないことを確認します。

次に、CreateEventIntentを使って イベントを作成します。 以前とまったく同じように。

作成されたら、イベントが Spotlightインデックスに存在することを期待します。 そこで再度クエリします。 結果がちょうど1つあり、 タイトルがマッチすることをアサートします。 テストを実行します… そしてパスします。 このテストは毎コミットで 実行できます。 Spotlight統合が 再び壊れた場合、 このテストが即座に 検出します。

クイックチェックで 確認しましょう。 イベントが確かに Spotlightにインデックスされていることを。 素晴らしい！ フリートコマンダーが Spotlightの速さで答えを得られます！

Viewアノテーションは、ビューが現在表示している エンティティをシステムに伝えます。 これによりSiriは画面上に何があるかを 理解して直接操作できます。 CometCalはSiriに 画面上のEventEntityを伝えます。 イベントに移動するたびに。 イベントを表示中に、 予期せぬワームホールジャンプで 電話が手から飛んでいった場合、 いつでも呼びかけて「Siri。 このイベントは何時ですか？」と言えます。

理想的には、Viewアノテーションが Siriに画面上の正確なイベントを伝え、 Siriがすぐに答えます。 しかし、そのアノテーションが壊れると、 Siriは画面上に何があるかわかりません。

次元間移動は私には 認めたい以上に頻繁に起きるので、 この機能が動作することが 本当に必要です。 AppIntentsTestingの助けを借りて バグを修正しましょう。

イベントページに 移動することから始めます。 OpenEventIntentを使って。

このテストはXCUITestバンドルに 存在するため、 XCUI Automationを使って アプリが 画面に正しいイベントを 確かにレンダリングしていることを確認できます。

次に、Eventエンティティの viewAnnotations()メソッドを呼び出せます。 このメソッドはEventEntityの Viewアノテーションのリストを取得します。 システムが現在画面上にあると 報告しているもの。

アサーションの時間です。 まず、画面上にイベントが1つだけあるので、 システムがViewAnnotationオブジェクトを 1つだけ返すことをアサートします。

次に、タイトルに基づいて Eventエンティティが正しいことをアサートします。

ViewAnnotationオブジェクトには entityプロパティがあります。 実際のエンティティ表現を 保持しています。 そのため、dynamic member lookupを 使用して タイトルなどの特定のプロパティを アサートできます。 テストを実行します。 失敗しました。

EventDetailViewに移動して 原因を調べます。 問題はEntityIdentifierにあります。 誤ってイベントの カレンダーIDを識別子として渡していました。

修正はシンプルです。 イベントのIDに変更します。

テストを再実行します。 今度はパスします。

次に次元間移動が 不意に起こった時でも、 「Siri。このイベントはいつですか？」と 言えます。

そして正しい返答が得られます。 「どこですか？」とフォローアップすることも できます。

Siriが場所を 教えてくれます。

今日は多くのことをカバーしました。 一歩引いて、 AppIntentsTestingが App Intentの開発ワークフローを どう強化できるかを見てみましょう。

基本的な型を実装することで App Intentの旅を始めます。 アプリのアクション、 データ、クエリです。 AppIntentsTestingを使えば、これらの型の 基本的な動作を検証できます。

これらのテストはApp Intents統合の ユニットテストとして機能します。

基本がテストされたら、 アプリをシステムと より深く統合します。 エンティティでビューをアノテートし、 Spotlightにdonateし、アプリ間でデータを渡します。 AppIntentsTestingを使えば これらの統合もカバーでき、 アプリの体験を検証できます。 ユーザーがアプリを使う 様々な方法で。

これらがApp Intentの 統合テストになります。 すべてのレイヤーでカバレッジが得られれば、 アプリは準備完了です。 本当に強力な体験を 解き放つために。 この段階で、インテントを手動で テストしてください。 SiriとショートカットアプリでExerciseして、 ユーザーが体験するのと 同じように体験してください。 それがAppIntentsTestingです。 インテント、エンティティ、enum、 クエリ、システム統合をテストできる単一の フレームワーク。すべてアウトオブプロセス、自動化。

CometCalサンプルプロジェクトを ダウンロードして試してみてください。 アプリの完全なテストセットを 探索してください。

このトークはAppIntentsTestingの 可能性の表面をなぞっているに過ぎません。 完全なAPIリファレンスについては ドキュメントをご確認ください。 App IntentでSiri体験を 構築する方法を学びたい方は、 このトークをご覧ください。 さあ、この世界を超えた何かを 構築する準備ができました！ ご視聴ありがとうございました！