Xcodeでテストする

(音楽)

(拍手) “Testing in Xcode”へようこそ 私は アナ･カリノフです 同僚のスチュアートと イーサンも登壇します まず XCTestを用いた Xcodeのテストを紹介します 次に Test Plansの機能を 説明します 最後に 継続的インテグレーションへの 応用の話をします

まずは XCTestです

XCTestは 自動テストの フレームワークです ビルトインサポートも 用意されています どんなプロジェクトでも テストは重要です ソースコードのバグを 発見できます また 要求を整理できます つまり 期待される動作の テストをして そのまま作業を進めるべきか 判断できます

まず テストのプランを立てる際に 必要な考え方をまとめます ピラミッドモデルで バランスを考えましょう 完全性 品質 実行速度の バランスです

土台となるのは ユニットテストです 単一のコード 一般には関数をテストします 関数に変数を代入し アウトプットをチェックします ユニットテストは 短く 単純で 迅速です あらゆるテストの基礎なので すべての関数に 実施すべきでしょう

次は インテグレーションテストです まとまったコードを 検証するのに用います 個別のサブシステムや クラス群を対象として 一緒に正しく動作するかを 確認します

位置はユニットテストの上です まず 個別の関数を確認してから 大きな部分を テストするからです インテグレーションテストの方が 数は少なく済みます 時間がかかる分 一度に多くテストできます

最後は UIテストです ユーザが使用する段階の 動作を見ます 本当に期待どおり動くかを 確認できます 時間は最も長くかかります ですが 全体を確認するのに 不可欠です

UIは頻繁に変わるため テストにも調整が必要です このピラミッドで ３種類のテストのバランスが分かり 必要なテストを 確実に実施できます

バランスについて説明しました 次は XCTestの提供する ツールです

XCTestのユニットテストは ソースコードを対象とする テストです ユニットテストと インテグレーションテストが含まれます

UIテストは UIに対して実施し 適格性を徹底するための物です これはブラックボックステストです 実際の関数やクラスの知識に 依存しないからです 最終的に問題がないことを 確認することができます

最後に パフォーマンステストは 何度も実行して 平均の時間や メモリ使用量などを見ます 新たな不具合がないか 確認するためです 今日は ユニットテストと UIテストを説明します

Xcodeプロジェクトの 新規作成時に― ユニットテストと UIテストを 選択するのが簡単です

プロジェクト内に ユニットテストとUIテストの クラスがあるのが分かります 自動で作成され ナビゲータに表示されます

テストクラスと その中のケースを― 書くためのテンプレートも 提供されます

テストクラスを 詳しく見てみましょう XCTestフレームワークを インポートしています このクラスは XCTestCaseの サブクラスなので Xcodeが そのメソッドを利用できます

使用したいメソッドには 頭に“test”を付け 何をするか分かる名前を 付けましょう

ひし形マークが示すのは そのテストが― 実行可能ということです このテストでは アサーションAPIで コードの検証をします ここでは XCTAssertEqualが 最初の２つの値が 等しいことを確認します 異なれば テストは不成功です テスト結果が成功なら ひし形が緑色に変わり チェックマークが入ります 必ずしも こうはならず 不成功なら 赤色になり “X”が入ります 行がハイライトされ― 問題点を示す メッセージも表示されます XCTAssertEqualに渡す 文字列も表示され さらに情報を与えてくれます ここでは ソースコードの エラーか― 予期しない数値に 初期化されたようです ソースコードに戻り 修正して 成功するまでテストします

テンプレートには setUpと tearDownメソッドもあります このブロックは 目的に応じて テストの前後に― 必要な作業をするものです

各テストの前にsetUpを呼び出せば UIテストで アプリケーションを 立ち上げてくれます

次に テストを実行します その後 tearDownが データや状態に加えた変更を 一掃してくれます 後のテストへの影響を残しません

では デモに進み テストの書き方をお見せします

(拍手)

旅行アプリケーションです 世界中の旅行先を探して 計画を立てられます これに新機能を追加して 現在地のサンノゼからの 距離を表示させたいと思います DistanceCalculatorという クラスを書きました ここで定義する構造体Cityに 都市名や座標が入っています

今は リストを辞書に入れています 後に移動する予定です

cityという関数が オプショナル型を返し 辞書にある都市を検索します

使用するメインの関数は distanceInMilesです ２つの都市名の文字列を取得し その距離の数値を戻します 都市名が辞書になければ エラーを投げます

もう１つ distanceInMilesという ヘルパー関数があります 構造体Cityを取得し 距離を返します Core Locationフレームワークを 使用するので 大きな仕事をしてくれます このクラスの ユニットテストを書くため DistanceCalculatorTestsという クラスを作りました ソースコードも見たいので 下に もう１つエディタを開き DistanceCalculatorを開きます

まず 関数cityのテストを書きます

ユニットテストです 名前は “testCoordinatesOfSeattle”とします 各テストクラスに 特定のケースを選択して 動作を確認します ここでは“Seattle”を代入して 正しい座標が返るかを見ます まず DistanceCalculatorを 初期化して calculatorを見つけます

では 書き始めます 関数を呼び出します ですが cityが返すのは オプショナル型です 値がnilでないことを 確認したいです それには このAPIを使います XCTUnwrapを用いて 値が有効であることを確認します

Seattleのcalculatorを 呼び出します エラーメッセージが出ます エラーがハンドルされない 場合があるようです cityが nil値を返した時 確実にスローするようにして 問題を示す必要があります

Seattleに対する値として city変数が得られました アサーションAPIで 緯度と経度が正しいことを 確認します

ひし形をクリックして実行します

アプリケーションが起動し テストが実行されます

テストは成功したようです

次は distanceInMilesクラスの テストを書きます

関数名は testSanFranciscoToNewYorkとします 距離に対して 関数が返す値を見ます まず最初にすることは また DistanceCalculatorの 初期化です 毎回これをするので コードが繰り返しになります そこで calculatorという クラス変数を宣言します そして setUp関数を利用して 毎回 テスト前に初期化します

では 書き始めます

distanceInMilesを呼び出し サンフランシスコからニューヨークの 距離を定義します アサーションAPIで 正しいかを確認します

テストを実行しましょう

今回は不成功のようです 問題ナビゲータから― エラーメッセージを確認します

テストは不成功で エラーメッセージが出ました 比較対象とした数値の精度が 実際に求める値より 細かすぎたようです

そこまでの精度は必要ありません ユーザに示したいのは マイル単位の整数です そこで精度の引数を追加し

“１”とします XCTAssertEqualの 判定に余裕をもたせ １までの差なら認めるようにします では もう一度やってみます

成功です (拍手) ここまでに ２つのテストを書きました いずれも関数に有効な値を入力し 有効な値が返されました ですが 他のケースも テストしたいです エラーが正しくハンドルされるか 確認したいのです 次に書く関数は ネガティブなケースです クパティーノは データベースにありません 大都市を想定しているので クパティーノは対象外です

ですから 呼び出すとエラーが投げられ 存在しないと言われるでしょう

XCTAssertThrowsErrorを使います

クロージャを用いて 投げられたエラーを見て XCTAssertEqualと比較して 確認します さて この３つのテストを 一度に実行して すべての動作をテストします テストナビゲータに テストターゲット テストクラス そして― テストケースが表示されています 選んだ階層下のテストが すべて実行されます “DistanceCalculatorTest”の ボタンを押すと ３つが実行されます 緑のチェックマークが出たので すべて成功です

列の上で Command + クリックすると　

実行するものを選べます 全部は実行したくない時は― カテゴリを選べます 右クリックで選択します

あるサブセットを選び 後に同じサブセットを 実行したい場合― “Product”から “Perform Action”で 最近実行したテストを選べます いくつかのユニットテストが 書けたので クラスをUIに実装します distanceTextを表示して クラスを実行します

都市名の下に 現在地から― その都市までの距離が 表示されます

さて 新たにUIテストクラスを 作りました DiscoverUITestsです このクラスにはsetUpがあります continueAfterFailureは “false”にしています テストが不成功の場合― UIが予期しない状態に なっています 大抵は 画面の状態が分からず それ以上 操作できません

また アプリケーションを 確実に起動させます

ユニットテストと同様に 書き始めます このテストの目的は まずアプリケーションを開くこと そしてパリのアイコンを表示させ 距離が正しいか確認することです

テスト開始時に“Discover”タブが 選択されるようにします UIのエレメントを探して 操作することができます ここではDiscoverという ボタンを探します

それをタップして タブを表示させます このアクションの後― 正しい画面が出ているか 検証します 期待どおり 画面上に サンフランシスコが― 見えていることを確認します

XCTAssertを用いて 静的テキスト “San Francisco”を確認します isHittableは エレメントが存在し― 操作できることを 保証してくれます

次は 画像を左にスワイプして パリの画面にします

実は この画像の操作が 分かりません 定義方法の不明な ラベルがあるためです そこで デバッガを使い UIの情報を取得します 26行目に ブレークポイントを設定し テストを実行します

起動して “Discover”をクリックし “San Francisco”を確認して デバッガで停止します

デバッガから 更に情報が得られます “po app”で正確なビュー階層を 印刷することもできます

これが 全エレメントのリストです 多すぎますね そこで 印刷の対象を絞り込んで すべての画像とします

画像のリストが出ました “san-francisco”はここです 文字列をコピーして デバッガを閉じ―

“sfImage”を定義して この識別子をもつ画像とします

クエリを要求して 左にスワイプします ここで UIの変更が テストに割り込まないよう パリが画面に見えることを 確認したいのです

XCTAssertで 操作可能か確認します 最後は 距離が正しいかの 確認です 再び XCTAssertを用いて 静的テキスト“5586マイル”が 表示されているか確認します ひし形マークから テストを実行します ブレークポイントを削除すれば―

通して実行されます

起動して Discoverを押し テキストを確認 左にスワイプして 文字列が正しいかを見ます (拍手) このテストでは “5586マイル”という― 静的テキストを探しています 現在地が本物かも気になりますね つまり サンノゼにいると 仮定しているのか 実際の位置に 基づいているのかです スライドに戻り テストの構成を見ましょう

テストを書く際の ターゲットは２つです ユニットテストとUIテストです ２つのテストは 実行方法が異なるため それぞれ別にする必要があります 各テストターゲットに クラスが含まれます ターゲットは 必要な数だけ クラスをもてます

各クラスに テストケースが含まれています ２つのターゲットで 完全に アプリケーションをテストできます もっとターゲットが 必要なこともあります プロジェクトが複雑になると 新たなフレームワークが必要です 独自のユニットテストターゲットが 含まれます さらに Swiftパッケージは― すでに テストターゲットを 定義しています このターゲットは 他のユニットテストと 同じように動作します

各ターゲットを 完全に書き直した場合― ソースコードを もれなくカバーできるでしょうか そんな時 コードカバレッジを使います これは XCTestの機能で テストで ソースコードの各行が 実行された回数を 可視化してくれるものです

これを有効にすると テスト後に― ナビゲータの“Coverage”から データを選択できます

各ターゲットとクラスの リストとともに 実際に実行された ソースコードの割合を― 見ることができます 直接 ファイルに切り替えられます ソースファイルを見ると エディタ右側のガーターに テスト時の その行の実行回数を示す― 数字があります 数字にマウスオーバーすると 情報が見られます

実行された行は緑になります ヒットしなかったセクションは 赤色です さらに テスト中に 選択されなかった条件など― ヒットしなかった個別の コードパスも分かります このツールでは ほかにも 情報が得られ テストを追加すべき領域が 特定できます

コードをリポジトリに追加する時 テストを含めれば 品質管理を徹底できます コードカバレッジを使えば 漏れも防げます テストに漏れがあると思う時は 更にテストを増やしましょう

テストは 早いほど 価値を発揮します コードと並行した テストスイートがあれば 新たな関数を書くごとに その信頼性を徹底できます アプリケーションの健康のために テストは不可欠です 次は スチュアートに― テストの活用方法を 話してもらいましょう (拍手)

ありがとう テストの基礎が分かったので Test Plansという 新機能の話をします テストを最大限に活用できます

テストを 一から書くとしても すでに完成されているとしても ぜひ聞いてほしい アドバイスがあります 異なる方法で 複数回 実行しましょう テストを修正しなくても Xcodeのオプションや 高度な機能を活用すれば より多くのバグを発見できます 具体例で説明します

各国語にローカライズされた アプリケーションで― いくつかのUIテストを書きました 開発時の言語 つまり英語で実行した場合― テストは成功する可能性が 高いでしょう

しかし 特定の言語でだけ バグが出るかもしれません その言語の文字列が表示されず UIのレイアウトも壊れています Xcodeの設定で 言語を変更して テストしてもいいでしょう 結果は不成功となるはずです あるいは 新たにテストを書いて 問題を再現することもできます しかし この問題が解決した後も 開発時の言語だけでなく 他言語でも 常にテストできるのが理想です

これは一例です 他にも何度かテストをしないと 見つからないバグがあります 例えば 実行順は アルファベット順とランダムが選べます ランダムでは メソッド間の― 隠れた依存関係を見つけられます 複数のサニタイザーも使えます アドレスサニタイザーや スレッドサニタイザーなどです 後ほど もっと詳しく説明します 任意のコマンドラインの引数や 環境変数も変えられます コードの特定部分を 改変したい場合に有用です テスト版のサーバや 模擬データを使う場合などです

スキームエディタを使えば さまざまな設定が可能です 各タブから アプリケーションの― 立ち上げ方を変更できます しかし どの設定でも 実行は１回のみです

今 やりたいことは テストを何度も実行することです そのための新機能が Xcode 11の Test Plansです

設定を変えて テストを 何度も実施できます

すべてのパターンを 一度に定義できるのです 複数のスキームで共有できます これまで スキームを複製して テストしていた人は― それを取り消し １つのテストプランに まとめることもできます

Test Plansは xcodebuildにも対応しており CIサーバや Xcode Serverで 使えます 既存のプロジェクトにも 導入できます 話すよりも デモを見てもらいましょう (拍手)

では― 先ほどのプロジェクトです まず テストプランファイルを 開きます プランの詳細が見られます テストは ターゲットごとにまとめられ さらに クラスやメソッドごとに 整理されています 表示内容は変えられます すべてを一覧で見ることも― 特定の領域内で 検索することもできます 一時的にテストを 無効にしたい時は “Enabled”のチェックを 外してください

ターゲット関連の設定を 変えるには― “Options”を押します

これは UIテストのターゲットなので 複数のシミュレータで並行して テストを実行すれば高速です そこで これを有効にします

“Configurations”タブに移ります 実行の方法や回数を 管理するタブです 左側に設定のリストがあります “Shared Settings”という 項目もあります 毎回のテストに共通する選択を ここで管理することができます 設定できる項目が たくさんあるのが分かります さまざまな引数を 変更することもできます ローカライズの設定や スクリーンショットの保存期間を 変えられます テストの実行順 コードカバレッジの有効化 サニタイザーやメモリ診断も 有効化できます

一部の項目は太字になっています 例えば “Environment Variables”です この太字が示すのは― カスタム値を与えていると いうことです テストの実行は アルファベット順でなく ランダムにしています

さて ここでやりたいことは 先ほどの例で示したように― 言語を変えて テストを２回実行することです 新たな設定を追加します ドイツ語を使うので 名前は“German”とします

１つ目の方は “US English”としましょう

US Englishの設定については 内容を変更せず そのままにします Germanの方は 言語と地域を カスタマイズします

今 設定を変更したので ポップアップメニューに― “Plan Default Value”という項目が 追加されました これは Shared Settingsから 引き継がれた値です カスタマイズを元に戻すときは これを選びます

さて 設定ができました 次に Test Plansの使い方を お見せします

“EventTests”という ユニットテストの― ファイルを開きます 構造体をテストするものです ファイル内のひし形マークを どれかクリックすると テストプランの設定が ２つあるので テストは２回実行されます すべてのテストを 実施したい状況であれば それでいいでしょう しかし そうでない場合もあります ひし形を Option + クリックで １つだけ選択できます メニューが出るので選ぶだけです

これで…　ありがとう (拍手) テストナビゲータの― テスト上で Control + クリックでも 同様のメニューが出て １つ選んで実行できます

テストナビゲータでは どのテストプランが― アクティブなのかも確認できます ここでは プランは１つですが 複数にすることも可能で 後ほど話します

とりあえず すべての設定で実行します Xcodeがプロジェクトをビルドし シミュレータで テストを２回実行します 終わりました 問題が１つあったようなので 詳細を見ましょう レポートナビゲータをクリックして 最新のアクションを見ます これを見て分かるのは ほとんどは緑マークで成功ですが

１つだけ問題があり 赤色のアイコンになっています このレポートでは すべての結果を― 分かりやすく示してくれます これを見ると分かるのは ２つのうち１つの設定で 不成功だったようです さらに開くと 問題が分かります 想定していない ドイツ語のテキストが原因でした コードに戻って 修正する必要がありますが それは あとでやります その前に テストレポートの 改良点を紹介します このように ２つの設定で 結果の異なるテストだけを 見たい場合― “Mixed”ボタンを押せば簡単です

特定の設定の結果だけを 見たい場合は このボタンを押して １つの設定を選択します

Test Plansのデモでした スライドに戻ります (拍手)

実演を見てもらったので その仕組みを説明します テストプランのファイルは JSON形式で 拡張子は xctestplanです 内容は 実行するテストと その実行方法を記述する すべての設定です

テストプランファイルは 通常のプロジェクトに含まれ 複数のスキームから参照できます

テストの設定は １回の実行を記述するものです 各設定には 自由に名前が付けられます 意味のある名前を 付けるのがいいでしょう その名前が メニューやレポートに 表示されるからです

設定には ビルドや実行の あらゆる選択が含まれ Shared Settingsから 引き継ぐこともできます 毎回の実行で 同じになる設定があれば 繰り返さず 一度に定義できます

これはテスト設定で変更可能な 項目のリストです エディタの Configurationsタブで 選べます

Test Plansを使い始める時―

既存のプロジェクトは 変換する必要があります まず スキームの編集を選び

“Test”の画面に行きます

“Convert to use Test Plans”という ボタンがあります

これを押すと 変換方法を選ぶ シートが表示されます

１つ目は 既存の設定から 新規ファイルを作成します 最初に変換するスキームでは これを選びます

既存のテストプランも選べます これを選ぶと 既存のプランが表示されます すでに変換済みのスキームがあり 別のスキームで同じプランを 共有したい時に選びます ゼロから作ったプランも使えます

さて 変換して使い始める 方法が分かりました そこで いくつかの活用例を 紹介します

これは基本的な例の１つです それぞれの枠は １つの設定を表します アドレスサニタイザーと スレッドサニタイザーが有効です サニタイザーは Xcodeに内蔵されるツールで 手動で再現しにくいバグを 特定してくれます サニタイザーは 合わせて使うこともできます しかし このような構成にすると 最大限に利益を得ることができます

プロジェクトにC言語や Objective-Cが含まれる場合 未定義動作サニタイザーを 各設定で有効化します

２カ所に設定されているのが 分かるでしょう 各設定で繰り返されます

これを Shared Settingsに してもいいでしょう 自動的にすべての設定に 引き継がれます

互いに適合しない サニタイザーを用いて このように設定したとします その場合両方の設定を実行すると Xcodeは２回 ビルドを行う必要があります 継続的インテグレーションでは 理想的です テストの完全性が増すので ビルド時間は気になりません

サニタイザーだけではありません テストプランでは さまざまな言語や 場所の設定も可能です 例えば 米国 韓国 イタリアなど― 数に制限はありません

UIテストの実行に この設定を使用できます Shared Settingsの機能で それぞれのスクリーンショットも 取得できます これは Xcode 11の新機能で 成功したテストでも すべて スクリーンショットを 保存できます 各言語のデータを 集められるのです

ローカライズの際に 参照することもできるし App Storeに載せるために 使うこともできます

(拍手) ローカライズに関する その他の情報は― “Creating Great Localized Experiences”をご覧ください

最後に こうした設定は さまざまな― 組み合わせが可能です 例えば このようなプランでは ３通りの設定が考えられます

１つはメモリの安全性を重視し アドレスサニタイザーと Zombie Objectsを有効にします

２つ目は並行処理を重視し スレッドサニタイザーと 未定義動作サニタイザーが有効で 実行順はランダムです

最後は 追加的な診断を 行う設定です カスタム環境変数を設定し ログ収集のきっかけを 増やすようにします 更に テストが成功した場合でも Attachmentsを保存します

これは難しい例ですが テストの実行における 柔軟さが分かるでしょう

以上が Xcode 11のTest Plansです 設定を変えたテストで 最大の効果を得られます 継続的インテグレーションについては イーサンが話します (拍手)

ありがとう テストを最大に活用するには さまざまな設定で 実行することです 継続的インテグレーションでは それが可能で テストのビルドと実行を 自動化できます 皆さんが 個々のテストに 集中する間に あらゆるデバイスのテストを 最大限の網羅率で 実行してくれます Xcodeでは 主に ２つのソリューションを選べます １つは ビルトインの Xcode Serverです ビルドとテストを行う場を 最小限の設定で作れます ２つ目は 独自の設定を構築することです 細かい要件や 既存のインフラがある場合は 理想的な選択肢です カスタム設定が必要な場合― Xcodeには強力なツールが 備わっています

ここでは２つ目の選択肢に注目し 完全なカスタムCIの構築を学びます パイプラインは ４ステップから成り それぞれ異なるツールを使います

ステップ１は 専用マシンでテストをビルドします

ステップ２では そのテストを― 各デバイスで実行します デバイスは テスト用の 別のマシンに接続します

ここまでで ビルドとテストの結果が出ます これが次の２ステップの データ元となります

ステップ３は テストとビルドの失敗を Issue Trackerに登録します

ステップ４は コードカバレッジを追跡して 網羅率がどうなっているか 理解します

まず 最初の２ステップの ビルドと実行です

これには xcodebuildを使います xcodebuildは コマンドラインインターフェースです その背景には xcodebuildシステムと XCTestの テストハーネスがあります

テストの実行方法は２つあります １つは ビルドとテストを 一度に行います testアクションを用いて テストしたい物の名前と― テストの実行先を提示します

２つ目は ビルドの後に テストします xcodebuildを２回に分けて 起動します 主な使用例では １つのマシンをビルド専用とし もう１つをテスト専用とします その方法を説明します まず build-for-testingを起動し 前に述べたパラメータを渡します ビルドプロダクトと xctestrunファイルが 生成されます xctestrunファイルは テスト時の指示を― xcodebuildに与えます

次に test-without-buildingを 起動します xctestrunファイルを渡します これでテストが実行されます

独自のxctestrunファイルを 作れば test-without-buildingの 動作を調整できます ファイルの詳細は manページをご覧ください フォーマットが 異なることがあるので ビルドと実行には 同バージョンの Xcodeを使用します

xcodebuildは 複数デバイスでの 同時テストに対応しています さまざまなデバイスを 最大限にカバーできます 特にUIテストに有用です UIはサイズクラスにより 異なるためです

複数の実行先への対応について 詳しくは― 2018年の“What's New in Testing”を ご覧ください

ここまで xcodebuildの 基本を説明しました 次は テストプランに固有の 選択肢の話です

複数のプランがあるスキームの場合 showTestPlansで一覧を見られます

いくつかのワークフローが 利用できます 完全なテストスイートを含む 長いテストプランや 短時間のスモークテストが あります このうちの１つを デフォルトと見なします スキームエディタで設定できます 特に指定がなければ デフォルトプランが実行されます

デフォルトを無効にするには 実行したいプラン名を渡します

ここまでを念頭に置き パイプラインに補足します

まず xcodebuildを用いて ビルドプロダクトと― xctestrunファイルを生成します

次に 実行用マシンで test-without-buildingを起動し 各デバイスのテストを実行します

この２ステップで得られた結果が 次の話につながります Result Bundleです 今年 ぜひお伝えしたい話です

まず Result Bundleとは何でしょう Xcodeが生成するファイルで ビルドと実行の結果の データが含まれます ビルドログなどのアセットが含まれ コンパイルされた ファイルが分かります

テストの成否も示されます

実行時のコードの網羅率も 見られます

XCTAttachmentを用いて 作成された― アタッチメントも含まれます

Result Bundleの作成は resultBundlePathを渡すだけです

さて Result Bundleの作成方法が 分かりました xcodebuildを起動して resultBundlePathを追加し ビルドとテストの結果を 生成します

Result Bundleは 前からある機能ですが Xcode 11では フォーマットが変わりました 第一の利点は 効率性が最適化されたことです Result Bundleのサイズは ４分の１になりました 特に 継続的インテグレーションでは Result Bundleを高速に 生成できます

第二に Result Bundleを 直接開くことができ 簡単に 詳しい結果を見られます

第三に Result Bundleの内容に プログラムでアクセスし 独自のCI設定で利用できます

開くにはダブルクリックすれば 見慣れたUIで 閲覧できます テストの成否を確認し ビルド失敗の原因を調べ― コードの網羅率も見られます

(拍手) ありがとう プログラムでアクセスするには xcresulttoolという コマンドラインを使います

Result Bundleのデータに 完全にアクセスできます データはJSON形式です JSONのフォーマットは 公開されています

xcresulttoolを活用して ビルドやテストの失敗を Issue Trackerに追加します

ビルド失敗を抽出するには getコマンドを用いて Result Bundleのパスを渡します

結果は 出力されたJSONの オブジェクト内に 見つけることができます エラーメッセージとともに ソースファイルと行番号が 示されます

テスト失敗も JSONの中に テスト名とメッセージが 出力されます

全く同じ手順でなくても 大丈夫です xcresulttoolの大きな利点は JSONが公開フォーマットで あることです xcresulttool自体が formatDescriptionを用いて スキーマを記述します スキーマに 全オブジェクトが 記載されています 自分で書く際にも 参考にしてください

詳しい情報は manページをご覧ください

xcresulttoolが分かれば ステップ３に進めます Result Bundleから 失敗を抽出して Issue Trackerに登録します

ここまで来たら 残るは １ステップです コードカバレッジに 減少がないかを見ます

xccovというコマンドラインを 使います テキストまたはJSON形式で レポートにアクセスできます viewコマンドを起動し Result Bundleを渡します

ターゲット ソースファイル 関数 メソッドの 網羅率を見ることができます

単にレポートを 見たいわけではなく ２つのレポートを比較して 変化を見たい場合は― diffコマンドを使います ２つのResult Bundleのパスを渡すと 結果が出ます この例では コードカバレッジが 50％増加しているのが分かります

xccovにも manページがあるので ご覧ください

これが最後のステップです xccovを用いて コードカバレッジを抽出しました

継続的インテグレーションは 完璧です xcodebuildでテストを実行し xcresulttoolで失敗を抽出 xccovで網羅率を見て 完全なパイプラインを 構築できました Xcodeのツールが どれほど強力なものか 伝わったことと思います お見せしたのは一例ですが 可能性は無限です

たくさんの話をしたので おさらいします まず Xcodeのテストを 紹介しました ユニットテストと UIテストの 実行方法も学びました

テストを体系化し 設定を変えて何度も実行できる― Test Plansを紹介しました 最後に 継続的インテグレーションの 構築ツールを学びました

ウェブサイトで 今日のスライドを入手できます Xcode 11のリリースノートも ご覧ください コードのパフォーマンスを 測定するAPIに興味があれば このあとの“Improving Battery Life and Performance”をどうぞ ラボでもお待ちしています (拍手)