不具合検出テストを書く

不具合検出テストを書く

不具合のため計画：最も手強いバグでさえも発見し、診断するのに役立つ有効なテストをデザインしましょう。最良のコードにおいてでも、隠れた問題を発見できるように、XCTestを使った自動テストの改善方法についてお伝えします。問題のトリアージを容易にする不具合検出テストの準備方法、インターフェースの問題を解決し、素早く修正できる方法もお伝えします。このセッションを有効に活用するためには、XCTestフレームワーク内でUIテストを書くことに慣れていることが望ましいです。テストツールの詳細については、“The suite life of testing”に進んでください。

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

WWDC22
- Xcode Cloud用の高速で信頼性の高いテストを作成する
WWDC20
ダウンロード

“ようこそ　WWDCへ” こんにちは　WWDCへようこそ “不具合検出テストを書く” “不具合検出テストを書く”へようこそケリー･キーナンですこのセッションでは― 私が長年 XcodeでUIと統合テストを書いてきて学んだ教訓をいくつか紹介します UIテストが主ですが― 多くの教訓は単体テストにも応用できますテストを書いたのがコードを書く前か書いた後かにかかわらず― 一番の原動力はテストをグリーンにすることですテストが成功すればこのアイコンが現れ― 製品が出荷できるからですでも今年は “不具合検出テストを書く”をモットーにしますいいテストはバグを発見できます不具合に備えましょうテストというのは書くのは１度ですがトリアージは何度も行われますテストはバグが見つかると失敗しますそれがテストの目的です私のテストはすべて連続した統合システムで走らせます不具合をトリアージするためのツールはテスト結果バンドルです今回はテスト結果バンドルだけでより楽にトリアージする方法を紹介しますテストをより堅牢なものにし― テストのデバッグでなく製品の不具合のトリアージに集中するためですテストのテンプレートの流れは― セットアップ　テスト　テアダウンですテストのセクションはアクションとアサーションに分解できますこのセッションではこれをテーマとしますではテストのセットアップから始めましょう私はここで必要な前提条件を宣言し― テスト前に環境とアプリケーションの状態を設定します Xcode 11.4では新しいsetUp関数を導入しました setUpWithErrorですスローして― セットアップ中に投げられたエラーをキャッチまたはパスできるようにします既存のsetUpメソッドを現代化し― エラー管理に活用すると便利でした setUpWithErrorメソッドを使い― 実行前にテストに必要な初期状態を設定します過去のテストでアプリケーションの状態やテストで使うデータが変更されているかもしれないからです
この例では continueAfterFailureを“false”に設定し― 問題があればただちにテストが失敗するようにします複数のエラーを待たずに最初のエラーを早く見つけやすくなりますまたこのクラスでは各テストでアプリケーションを起動するようにしますテクニックの１つとして― launchArgumentsと環境変数を活用しアプリケーション内で状態を迅速に設定しますすべての状態に使うべきではありませんでも必要なケースもあるでしょう例えばテスト中に 2ファクタ認証をバイパスする場合などですこの例ではメニュータブをバイパスして― レシピタブから始めるために使っていますこうした小さな変更で不要な作業が削られテストスピードが改善しますでも何よりレシピタブのテスト結果を見たいという時に― メニュータブの不具合をトリアージせずに済みますまとめると setUpWithError() throwsでエラー処理を改善クラス内の各テストで共通セットアップタスクを実行します例えばアプリケーションの起動です launchArgumentsでアプリケーションとやり取りして状態を設定そして製品変化を取り入れ状態を迅速に設定しテストに集中します次のステップはテストの実行ですテストではアクションを実行し― 完了をアサートすることに集中すべきですではアクションをより楽にトリアージする方法を見ましょうまず考えるのは― 各テストに目標を持たせることです目標はテストのタイトルに反映すべきですこの例では材料リストの正確さをテストしていますテストが実行する唯一のアクションは Berry Blueレシピを選択することですアクションを最小限にすることで後で不具合のトリアージを楽にしますこの列をタップするとレシピが現れ― アクションの結果として材料リストを確認できます結果バンドルでは― テスト名のおかげで何を確認するテストかすぐ分かります名前と言えば― UI要素のラベルはよく変わることを経験から学びましたそこで予防策としてすべての文字列値に列挙型を使いますそうすればUIが変わった時― 簡単にテストをアップデートして変更に対応できます UI変更のテストをアップデートする時間を節約するだけでなく― 気づきにくいスペルミスのせいでテストが失敗する回数を最小限にできます文字列を列挙型に集めたようにミスを最小限にする他の方法として― ヘルパー関数に共通コードを組み入れることです複数のテストで同じコードパスが使えますこの例では複数のテストがスムージーリストにアクセスし― レシピを選択します共通テストパスを引き抜くことによりコードを複製せずに― テストエラーを減らすためパスを堅牢にすることに注力できます他にもテクニックとしてアプリケーションのドメインをモデル化したものを軸に― テスト言語を設計する方法がありますそうすればテストにアプリケーションの言語が反映されますこの例では FrutaAppにスムージーリストを要求し― スムージーリストでアクションを実行できます例えばレシピを選択すると― レシピUI要素が返されますアプリケーションと下位レベルの要素を把握するために作成した― FrutaUIElementクラスに基づいていますこうすることで共通コードをオブジェクト指向的にしましたテストは関数的で要素やクエリーに基づいていますが― 可読性のためにオブジェクト指向の環境をシミュレートできますこれにより私が考えるアプリケーションを一連のサブビューとしてマッピングするコールをテストで行うことが可能になりますこのモデル化の結果― 各要素でより少ないヒエラルキーの作業になりますそしてクエリーを要素のサブ要素だけに集中させることができますこれまでに私たちが共有したテストコードはかなりの量になりましたそこで製品コードと同じように扱い― テストの共有フレームワークを作りました Swiftパッケージを使ってテストコードを共有するのもいいでしょう複数のアプリケーションで共有する場合は特にですまとめると明確な目標を定めてテストを設計します列挙型を使いヘルパー関数に共通コードを組み入れ― UI変更の対応を簡略化します UIヒエラルキーを反映するためテストでオブジェクトをモデル化しますフレームワークやSwiftパッケージを使って― コードを共有します次の話は私の大好きなテストアサーションテストの核となる部分ですテストアサーションとエラー処理に関して不具合をトリアージしやすくする上で― 私が学んだ教訓を紹介します１つ大いに役立ったのは― XCTAssert関数で任意のメッセージを使うことですデスクでテストのトリアージをするならメッセージを省いても構いませんが― 結果バンドルしかない時はいろいろと文脈が足りませんこの例では３が２とイコールでないことは分かりますが何が２なのか？メッセージを加えれば文脈を加えられます人は多くの時間アサーションメッセージを読んでいます私も頻繁に読みますだから自分になぜこの表現が失敗したかヒントを残しますでも時には自動システムによって読まれることもありますその場合はメッセージを適度に明確にしておきたいですそこで日付やタイムスタンプや固有のファイルパスなどを省きます同じ理由で失敗している複数のテストを認識するのに― メッセージを使うためですさらに正しいアサーションを使っているか― 確認を試みますこうすることで失敗した時に出る自動メッセージの関連性を高めます Xcode 12ではXCTIssueを追加しました不具合を報告する新しい下位レベルの方法です詳しい情報は― “Triage test failures with XCTIssue”をご覧くださいアサーションの落とし穴の１つは非同期イベントです非同期イベントのトリアージは時に苦労しますこの例ではレシピボタンをタップしますが― コードが何をするかによっては時間がかかりますすぐにレシピ要素を返しても― まだ存在しないかもしれません過去にはスリープを使ってテストに内臓タイムを与えたこともありますでもテストにやらせる必要はないし― 結果が出るのが遅れます XCTestは内臓リトライがありますがアプリケーションのコードによっては十分ではないかもしれませんだから私は waitForExistence(timeout)をお勧めしますポーリングができるので― タイムアウトより早く期待値が“true”ならその分待たずに済んだことになりますそして設計した環境内でテストが確定的にパスまたは失敗しやすくなります結果バンドルを見ると材料ビューを見つけるのに５分待ったことが分かりますもう１つの推奨は Optional型のアンラップですこの例ではパスされる文字列内のお気に入りのカウントを返したいのですが私はOptional型をアンラップしませんでしたローカルでコードを走らせる時― これはクラッシュに終わりテストは失敗しますランチの間に走らせて戻っても終わっていなかったら― とても悲しいです連続した統合環境で起きると― テストは失敗し結果バンドルに “不適切な信号でテストがクラッシュ”と出ます Optional型をアンラップすればこうなることを簡単に避けられます Swiftのメソッドを使い Optional型をアンラップします例えば“if let”でアンラップされた値をifブロックで使いますアンラップされた変数を後で使いたいなら “guard let”を使います “nil”に遭遇すると guardブロックで提供されるエラーを― スローできます３つ目の選択肢は nil coalescing演算子を使う方法です “nil”に遭遇するとデフォルト値を提供することができますこの例では空の配列です４つ目はXCTUnwrapを使う方法です XCTestフレームワークで提供されています “guard let”の簡略化で― “nil”に遭遇するとエラーをスローします XCTUnwrapを使うと― 結果バンドル内の自動生成メッセージに加えてコールから私のコメントが示されます Optional型をアンラップすることの最大の利点は― クラッシュするよりも優雅に失敗することで tearDownメソッドが呼び出されることです優雅な失敗と言えばエラーのスローについて話しましょう私のテストでは共有コードからアサートではなくスローするのがルールです共有コードは多くのテストで実行されておりいくつかのテストでは意図的にネガティブテストをしているかもしれません隠したものが表示されないか確認したりテスト目的でエラーダイアログを表示させたりするためですこの例では材料を確認する共有メソッドがあります以前追加材料が表示されるバグがあり修正されたかをテストするとしますそこでエラーを投げますエラーには私はよく descriptionに出てほしい値をパスします CustomStringConvertibleプロトコルの要件です description関数を使えばローカルでトリアージしない時結果バンドルに文脈的に関連性の高いエラーが示されやすくなりますローカルでトリアージする場合― Xcode 12ではコードで直接エラーのバックトレースが見られます共有コードのどこにエラーが隠れているか悩まずに済みますまたRuntime Issues Navigatorでもバックトレースを見つけることができますバックトレースの活用方法について― 詳しくは― “Triage test failures with XCTIssue”をご覧くださいまたこの結果バンドルにはユーザーが読めるdisclosure groupがあります当時私がどんなアクションを取っていたか文脈を示すためにコードが追加したものですここではすぐに私がBerry Blueスムージー内で Grapeを探していたと分かりますがこれは間違いですこうした道筋を示すため― 私はXCTContext.runActivityを使って名前を提供しますこれがブロック内で実行されたアクションと共に結果バンドルに示されます結果バンドルに組織性と文脈を加えるにはいい方法ですアクションに沿って読みやすくなりますまたrunActivityを使って― XCTAttachmentでattachmentを追加できますファイルや画像やデータなどの添付物が XCTContextかテストケースに追加され― 結果バンドルに出ます失敗したテストで追加のロギングを集めるには有効です CIシステムでは特にです先ほどファイルパスをアサートコメントに追加しないよう言いましたファイルパスとファイルそのものを― 添付して追加すればいいからです後からトリアージしやすくなりますテストは製品不具合をトリアージするのに必要なデータをすべて集めるのが仕事ですそのデータは後で手に入るか分からないからです時には実行が不要なテストがありますそういう時は XCTSkipやXCTSkipUnlessや XCTSkipIfを使い― メッセージを追加して走っていないテストを記録します主な目的はプラットフォームに関連のないテストをスキップすることです私が実際に使ったのは― 新機能のために書きたいテストをスタブアウトする時ですどのテストが未実装でどのテストが回帰したか分かるようになります３つ目はさまざまな理由から今は解決できないテストがある場合です不具合のトリアージを続けたくないが― 無効にしてテストを見失いたくない時です XCTSkipを使えばスキップされたテストも結果バンドルに出るので問題が解決した時テストを書いたり直したりせずに済みます
まとめると― アサーションメッセージを追加して関連するXCTAssert関数を使い― 結果バンドルの不具合に文脈を加えます Optional型をアンラップして― ランチ中にテストがクラッシュしないようにしますまたtearDownメソッドを呼び出させます非同期イベントやタイミング問題にはスリープでなく― waitForExistenceメソッドを使います他のテストでネガティブテストのエラーをキャッチできるようアサートはせず― 共有コードからエラーをスローします XCTContext.runActivityと attachmentを使って― 結果バンドルに文脈とコンテンツを追加します XCTSkipを使って今のシナリオでは実行したくないテストを― スキップします最後にテアダウンですテアダウンに関しては― 推奨することが３つだけあります１つはtearDownWithError() throwsを使ってテストを現代化し― 新しいエラー管理を活用します次にtearDownメソッドを使って― 不具合の分析を含めた追加のロギングを集めますそしてその時設定中に行った変更から環境をリセットします全体をまとめると― セットアップでは環境を変更しテストに必要な前提条件を確認しますテストのアクションではアプリケーションをモデル化した共有コードを通じてテストしたい必要なアクションを実行します次にヘルパーメソッドやエラーやテストアサーションを使って― アクションが正しく完了されることを確認しますそして最後にtearDownメソッドでデータを集めテスト後の片づけをしますこれらのテクニックと推奨事項が皆さんのテストをより堅牢なものにし― トリアージが簡単かつ迅速になることそしてテストをグリーンにし製品を出荷する手助けになることを祈っていますありがとうございました

class RecipesTests: XCTestCase {
    let app = FrutaApp()

    override func setUpWithError() throws {
        continueAfterFailure = false
        app.launchArguments.append("-recipes-tests")
        app.launch()
    }
}

3:09 - Use launch arguments

class RecipesTests: XCTestCase {
    let app = FrutaApp()

    override func setUpWithError() throws {
        continueAfterFailure = false
        app.launchArguments.append("-recipes-tests")
        app.launch()
    }
}

@State private var selection: Tab = 
       CommandLine.arguments.contains("-recipes-tests") 
       ? .recipes : .menu

4:12 - Design tests for a specific goal

func testIngredientsListAccuracy() throws {
    // Select Berry Blue recipe
    let recipe = try   
        app.smoothieList().selectRecipe
                           (smoothie: .berryBlue)

    // Verify ingredients list
    try recipe.verify(ingredients: 
        SmoothieType.berryBlue.ingredients)
}

4:56 - Use enums for string values

public enum SmoothieType : String {
    case berryBlue = "Berry Blue"
    case carrotChops = "Carrot Chops"
    case berryBananas = "That's Berry Bananas!"
    
    var ingredients : [String] {
        switch self {
        case .berryBlue:
            return ["Orange", "Blueberry", "Avocado"]
        case .carrotChops:
            return ["Orange", "Carrot", "Mango"]
        case .berryBananas:
            return ["Almond Milk", "Banana", "Strawberry"]
        }
    }
}

5:25 - Factor common code

let recipe = try app.smoothieList().selectRecipe(smoothie: .berryBlue)

public class FrutaApp : XCUIApplication {
   public func smoothieList() throws -> SmoothieList {
        let element = tables["Smoothie List"]
        if !element.waitForExistence(timeout: 5) {
            throw FrutaError.elementDoesNotExist("Smoothie List table")
        }
        return SmoothieList(app: self, element: element)
    }
}  

public class SmoothieList : FrutaUIElement {
    public func selectRecipe(smoothie: SmoothieType) throws -> Recipe {
       element.buttons[smoothie.rawValue].tap()
       return try app.recipe()
   }
}

5:49 - Model UI hierarchy in testing code

public class FrutaApp : XCUIApplication {
   public func smoothieList() throws -> SmoothieList {  }
} 

public class SmoothieList : FrutaUIElement {
    public func selectRecipe(smoothie: SmoothieType) throws -> Recipe {  }
}

open class FrutaUIElement {
    let app: FrutaApp
    let element: XCUIElement
    init(app: FrutaApp, element: XCUIElement) {
        self.app = app
        self.element = element
    }
}

8:17 - Use assertion messages

XCTAssertEqual(count, expectedCount, "\(SmoothieType.berryBlue.rawValue) smoothie is expected to have \(expectedCount) ingredients: \(expectedIngredients), however, there were 
\(count) found.")

9:21 - Asynchronous events

public func selectRecipe(smoothie: SmoothieType) throws -> Recipe {
    element.buttons[smoothie.rawValue].tap()
    return try app.recipe()
}

public func recipe() throws -> Recipe {
    let element = scrollViews["Ingredients View"]
    if !element.waitForExistence(timeout: 5) {
        throw FrutaError.elementDoesNotExist(
                        "Ingredients View scroll view")
    }
    return Recipe(app: self, element: element)
}

10:19 - Unwrapping optionals

func countFavorites(favorites: [String]?) -> Int{
     let favs = favorites!
     return favs.count
}

10:56 - Unwrapping optionals continued

if let favs = favorites {  }
guard let favs = favorites else { /* throw an error */ }
let favs = favorites ?? []
let favs = try XCTUnwrap(favorites, "favorites is nil, so there is nothing to count”)

12:19 - Throw errors from shared code

public func verify(ingredients: [String]) throws {
    try XCTContext.runActivity(named: "Verifying \(ingredients) exists in the Recipe screen.")
    { verifyingRecipe in
        for ingredient in ingredients {
            if !element.switches[ingredient].waitForExistence(timeout: 5) {
                throw RecipeError.ingredientDoesNotExist(ingredient)
            }
        }
    }
}

public enum RecipeError : Error, CustomStringConvertible {
    case ingredientDoesNotExist(String)

    public var description : String {
        switch self {
        case .ingredientDoesNotExist(let ingredient):
            return "\(ingredient) does not exist in the Ingredients View.)"
        }
    }
}

13:41 - Use XCTContext.runActivity()

public func verify(ingredients: [String]) throws {
    try XCTContext.runActivity(named: "Verifying \(ingredients) exists in the Recipe screen.")
    { verifyingRecipe in
        for ingredient in ingredients {
            if !element.switches[ingredient].waitForExistence(timeout: 5) {
                throw RecipeError.ingredientDoesNotExist(ingredient)
            }
        }
    }

14:02 - Add attachments to the result bundle

public func verify(ingredients: [String]) throws {
    try XCTContext.runActivity(named: "Verifying \(ingredients) exists in the Recipe screen.")
    { verifyingRecipe in
        for ingredient in ingredients {
            if !element.switches[ingredient].waitForExistence(timeout: 5) {
                let attachment = XCTAttachment(string: element.debugDescription)
                verifyingRecipe.add(attachment)
                 throw RecipeError.ingredientDoesNotExist(ingredient)
            }
        }
    }

14:50 - Use XCTSkip

let debuggingTests = false

func testSelectSmoothie() throws {
    try XCTSkipUnless(debuggingTests == true, "This test is not yet implemented.")
}

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

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

リソース

関連ビデオ

WWDC22

WWDC20