XCTIssueを使用してテストの失敗をトリアージする

XCTIssueを使用してテストの失敗をトリアージする

テストの失敗を役立たせましょう：Xcodeでの最新のテスティングAPIを使い、キャッチされていない問題をトリアージし分析する方法をお伝えします。テストワークフローを簡単にする方法、最高品質の製品を提供するのに役立つであろう失敗をコンテキストに組み込む方法について紹介します。よりよいトリアージをするためにテストをデザインする方法に関しては、“Write tests to fail”をご覧ください。 Xcodeのテストワークフローに関する最新の改善情報に関しては、 “Get your test results faster”、“Handle interruptions and alerts in UI tests”、“XCTSkip your tests”をご覧ください。

リソース
- - HDビデオ
  - SDビデオ
関連ビデオ

WWDC20
ダウンロード

こんにちは　WWDCへようこそ “XCTIssueを使用してテストでの失敗をトリアージする” 私はウィル　Ｘcodeのtestingおよびautomation エンジニアですテスト失敗時の検証に役立つ新しいAPIや改良点について説明しますテストスイートを管理するためには失敗の検証がとても重要です原因の究明に時間がかかるとリリースに間に合わずバグを含んだままの製品になるかもしれません進行中のプロジェクトではコードの変更がテストの失敗原因になり得ます失敗した時はこんな疑問が浮かぶでしょう何がどのようにどうして失敗したのか何よりソースコードのどこで失敗が起きたのか Xcode 12では APIを追加しテスト失敗のレポートUIを拡張効率的に疑問の答えを導き出しますこうした答えがとても重要なことからコーディングのパターンだけを特集したセッションがあります “Write Tests to Fail”をご覧ください
今回のセッションは４つの項目に分けました Swiftエラーやリッチな失敗オブジェクトスタックの呼び出しそしてワークフローです順を追って見ていきますがまず Xcode 12での失敗表示を確認しましょう
私は３歳の娘と一緒に “PlayGarden”というプロジェクトで裏庭にある植物やおもちゃ家具をすべて管理しています３歳とはいえ娘はテスト駆動開発を理解しすべてのビュークラスでエレメントのテストができています最近コードの重複が判明したのでユーティリティをリファクタリングしましたテストを１つ実行します失敗要因を入れているのでどう表示されるか見てみましょう
すぐにテストの失敗が表示され注釈はグレーでコメントされていますこれは注釈行のすぐ下の呼び出しで失敗が発生したということです Issue Navigatorで更に検証しましょう
Issue Navigatorでは失敗だけでなくテストコードのコールスタックも確認できますフレームをクリックすると失敗位置へ移動するので赤で表示された失敗ポイントを見ることができます他のフレームをクリックするとソースエディタには失敗が確認された位置からテストポイントまでのコードが表示されます失敗前後のコンテキストを素早く理解できるので解決に必要な時間が短縮されますではテストレポートに切り替えてみましょうこれは検証に優れた方法で連続的な統合システムから結果をバンドルする際に有効です
直近のテストレポートには失敗したテストが赤く表示され展開すると失敗したファイル行やメッセージが見られます更に下を見てみましょう Issue Navigatorと同じコールスタックが表示されましたフレームにカーソルを合わせると右側に２つのボタンが現れます１つ目はソースコードへ移動するジャンプボタンです
レポートに戻り２つ目のボタンを確認します Xcode 12ではこのアシスタントボタンで隣にエディタを開き参照するソースを表示しますテストレポートとソースコードを並べて確認でき Issue Navigatorと同様に失敗を検証できます
Xcode 12ではこのように失敗を確認します続いてテストのSwiftエラーについてです
Swiftのコーディングパターンに対応するにはテスト関数をスローすることで可能ですテストがスローするとエラーを元に失敗メッセージが作られますつまりエラーの処理にはこれまでの定型文ではなくテストはこのように書かれシンプルになりました最近まで XCTAssertでは失敗位置のソースコードやファイル行の表示ができませんでしたそのため今でも定型文を使う開発者もいますしかし Swiftランタイムの改良により iOSやtvOS 13.4　macOS 10.15.4ではスローされたエラーとソースコードの位置が分かるようになりましたこれで他の処理コードなしでエラーのコンテキストが得られますソースコードの改良に加え APIも追加しテストのsetUpとtearDownも便利になりました追加したAPIは以前のsetUpとtearDownの変形です
新しいsetUpWithErrorは元々のsetUp前に実行され tearDownWithErrorは元々のtearDown後に呼び出されます２つのメソッドは新しいテストファイルにありますこれらのAPIは同じテスト内で使えますが古いメソッドを維持する場合を除き新たなメソッドに切り替えることを推奨します次はリッチな失敗オブジェクトについてです XCTestは失敗を４つの値として記録しますメッセージファイルパス失敗が記録された行番号そして失敗の予想を示すフラグです予想された失敗は XCTAssertで記録されます予期せぬ失敗とはスローされた例外をXCTestが捉えることです
値はXCTAssertから recordFailure APIに渡され失敗を記録し Xcodeに伝えられていました
Xcode 12では XCTIssueで異なる値をカプセル化しています加えて新しい失敗データには明示型タイプの計算法詳細な記述内在するエラーと添付があります
XCTAttachmentは任意のデータをキャプチャするAPIでテスト自体か XCTContextによるアクティビティに添付します XCTIssueにも追加できるのでカスタム診断をテストの失敗とひも付けられます XCTestCaseには失敗を記録する新たなAPIがあり record(_issue:)はすべてのXCTAssertで使われます直接呼び出しやオーバーライドも可能です recordFailure APIは廃止されました recordFailureを直接呼び出しているかオーバーライドしているなら早めに record(_issue:)へ更新してください record(_issue:)を使う場合 XCTIssueをどう変更するのでしょう Swiftでは letでなくvarで宣言すると issueを変えられます Objective Cでは XCTIssueが変更できず NS mutableCopyに従います XCTIssueは多様な方法で失敗のトリアージを向上コールスタックもさまざまです最初にテストの失敗について重大な疑問は“どこで”だと言いましたそれを探すためにデータは常にファイルパスと行番号を含みコンパイラトークンを使いビルド時にキャプチャされます
シングルソースコードは単純なテスト向きですが１つ以上のテストで共有される関数にはあまり有効ではありませんこちらがその例です同じ関数を呼び出す２つのテストがあります失敗がある場合注釈がアサーションの横に現れますが失敗のマークがあることでテストメソッドが混乱しますそして失敗位置を示す情報はこれ以上ありませんヘルプ機能でソースの位置をキャプチャすれば改善できるので XCTAssertを呼び出す時に使用します表示とテストメソッドは向上しますがヘルプ機能に複数のアサーションがあると不明確さが残ります
XCTIssueならコールスタックをキャプチャしシンボル化できるので複雑なテストコードの失敗に対するコンテキストが増えます
コールスタックをキャプチャした同じ失敗の例です前のデモと似ていますがここでは“どこで”の疑問に焦点を置きますテストメソッドのグレーの注釈が失敗の発生行を示しヘルプメソッドの赤い注釈は失敗自体を表示します位置を伝える追加のコードや注釈位置を選択する必要もないので労力なく簡単に結果が得られます
最後に新たなAPIによる進歩的なワークフローを紹介します XCTIssueインスタンスのrecord(_issue:)でカスタムアサーションの実装が可能ですデータの正当性を立証するアサーションを記録したissueに添付として含めます
issue作成時は varを使います他のコードが構造体へ変更するからです情報はより長い初期化子に渡せますがこの方が読みやすくなると思います
次にデータをissueへ添付しましょうデータはXcodeのテストレポートに失敗と共に表示されるのでトリアージの間に調査しなぜ失敗したのか判断できますカスタムアサーションが呼ばれた位置をキャプチャ明確な表示のためですが必須ではありません失敗そのものの理解にはあまり役に立たないからです issueを記録しXcodeへ送るため record(_issue:)を呼び出します
もう１つのワークフローでは record(_issue:)をオーバーライドしテストクラスで記録された失敗を監視や抑制または修正しますこれは失敗時に必ず通過するメソッドでオーバーライドはテストクラスのアウトプットを制御します最初の例では監視のために record(_issue:)をオーバーライドしました superを呼び出し issueの記録を継続させることが重要です XCTestObservationCenterを使い監視もできますがここでのアプローチは１つのクラスで監視する場合です superが呼び出されなければ issueは抑制されていて記録が継続されずログもなく Xcodeに報告もされません
record(_issue:)をオーバーライドする一般的な理由は修正ですこのパターンのように添付を加えると診断に大きく役立ちますここでは簡単な文字列だけですが APIはさまざまな追加が可能ですそれでは重要な点をまとめましょうテストの失敗におけるトリアージは非常に重要ですコールスタックは失敗に関わるコードの位置を見つけやすくしますテストコードをより自然なパターンで書けるのでコードの再利用や他の作業にも注力できます XCTIssueは添付にも対応するのでカスタム診断のデータを追加しテスト失敗時の疑問を解決しましょうありがとうございました

9:52 - Implement a custom test assertion using XCTIssue

func assertSomething(about data: Data,
                         file: StaticString = #filePath,
                         line: UInt = #line) {

        // Call out to custom validation function.
        if !isValid(data) {

            // Create issue, declare with var for mutability.
            var issue = XCTIssue(type: .assertionFailure, compactDescription: "Invalid data")

            // Attach the invalid data.
            issue.add(XCTAttachment(data: data))

            // Capture the call site location as the point of failure.
            let location = XCTSourceCodeLocation(filePath: file, lineNumber: line)
            issue.sourceCodeContext = XCTSourceCodeContext(location: location)

            // Record the issue.
            self.record(issue)
        }
    }

11:12 - Override record(_ issue:) for observation

override func record(_ issue: XCTIssue) {
        
    // Observe, introspect, log, etc.:
    if shouldLog(issue) {
        print("I just observed an issue!")
    }

    // Don't forget to call super!
    super.record(issue)
}

11:30 - Override record(_ issue:) to suppress failures

override func record(_ issue: XCTIssue) {

    // If you don't want to record it, just return.
    if shouldSuppress(issue) {
        return
    }

    // Otherwise pass it to super.
    super.record(issue)
}

11:39 - Override record(_ issue:) to add an attachment

override func record(_ issue: XCTIssue) {
    
    // Redeclare using var to enable mutation.
    var issue = issue

    // Add a simple attachment.
    issue.add(XCTAttachment(string: "hello"))
    
    // Pass it to super.
    super.record(issue)
}

特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。

クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。

リソース

関連ビデオ

WWDC20