忙しい人向けの Triage test failures with XCTIssue - #WWDC20
4つのセクションに分けて解説していく。
Swift errors in tests
Xcode 12 では例外がスローされた場合、テストメソッド内にグレーで発生位置が表示され、Issue Navigator でコールスタックも確認できる。
Result Bundle でも同様にコールスタックを確認できる。これは CI のテスト結果から確認する際に便利だね。ホバーで表示されたアイコンからコードにジャンプすることも出来る。
最近の Swift ランタイムの改善によって、例外がスローされた位置を取得できるようになった。
setupWithError / tearDownWithError が追加された。既存の setUp / tearDown と共存できるけど、基本的には置き換えることを推奨する。
Rich Failure Objects
これまでテスト失敗時の情報は、以下の4つで構成されており、
XCTAssert は XCTestCase#recordFailure を呼び出すことで記録していた。
それが XCTIssue にカプセル化され、アタッチメントなどの追加情報も含められるようになった。
XCTAttachement は任意のデータをキャプチャできるもので、XCTIssue に追加することでテストの失敗と紐付けることができる。
XCTAssert は新たに追加された record メソッドを利用するようになり、既存の API は非推奨になった。record は直接呼び出すこともできるし、オーバーライドすることもできる。
Failure call stacks
共通のアサーションを作成した場合、どこで失敗したしたのか分からなくなる問題があった。
ソースコードの位置情報を関数で受け取るようにすれば分かりやすくなるが、共通アサーション内に複数のアサーションがあった場合、具体的な位置が失われてしまう。
XCTIssue はコールスタックをキャプチャ・シンボル化する。
何も工夫しなくても、以下のように『失敗した行』が灰色、『失敗位置』が赤で表示される。
Advanced workflows
新しい API を利用したワークフローについて見ていく。これはカスタムアサーションの例だ。まず、XCTIssue を var で宣言しているが、イニシャライザが長くなりすぎないように var の方が読みやすくなると思う。
次に失敗時の情報を XCTAttachement として追加しているが、これは原因を調査する時の情報として役立つ。
次に XCTSourceCodeLocation で発生位置を記録している。これは必須ではないけれど、より明確な表示になる可能性があるよ。（であってるかな？）
最後に record を呼び出して記録する。
record メソッドはテスト失敗時に必ず通過するので、override してカスタマイズするのに向いている。
例えば、監視して別のログに出力したり。
親クラスのメソッドをあえて呼び出さないことで、握りつぶすこともできる。
失敗を加工するのは、override する最も一般的な理由。ここでは”hello”という文字列を追加しているだけだが、実際には何でも追加できる。
まとめ
・テストの失敗を調査しやすくするのは重要。
・コールスタックはどこで失敗したのかをわかりやすくする。
・より自然にテストコードを書けるようになった。
・アタッチメントは「どのように？」や「なぜ？」を改善する。
免責
・本記事は公開情報のみに基づいて作成されています。
・要約（意訳）のみなので、詳細はセッション動画をご確認ください。
役に立った記事などありましたらサポート頂けると嬉しいです。