優れた開発者として、あなたはあなたが書いたソフトウェアのすべての機能とすべての可能なコードパスと結果をテストするために最善を尽くします。しかし、考えられるすべての結果と、ユーザーがたどる可能性のあるすべてのパスを手動でテストできることは非常にまれであり、珍しいことです。

アプリケーションが大きく複雑になるにつれて、手動テストで何かを見逃す可能性が大幅に高まります。

UIとバックエンドサービスAPIの両方の自動テストにより、すべてが意図したとおりに機能することを確信でき、開発、リファクタリング、新機能の追加、または既存の機能の変更時のストレスを軽減できます。

自動テストを使用すると、次のことができます。

• バグを減らす：コード内のバグの可能性を完全に取り除く方法はありませんが、自動テストによってバグの数を大幅に減らすことができます。
• 自信を持って変更を加える：新しい機能を追加するときにバグを回避します。つまり、すばやく簡単に変更を加えることができます。
• コードを文書化する：テストを調べると、特定の関数に何が期待されているか、条件は何か、コーナーケースは何かがはっきりとわかります。
• 痛みを伴わないリファクタリング：開発者として、特にコードの大きなチャンクをリファクタリングする必要がある場合は、リファクタリングを恐れることがあります。ユニットテストは、リファクタリングされたコードが意図したとおりに機能することを確認するためにここにあります。

この記事では、iOSプラットフォームで自動テストを構築して実行する方法について説明します。

ユニットテストとUIテスト

ユニットテストとUIテストを区別することが重要です。

に 単体テスト テスト 特定の機能 下で 特定のコンテキスト 。単体テストは、コードのテストされた部分（通常は単一の関数）が想定どおりに機能することを確認します。たくさんの本があり、 ユニットテストに関する記事 、そのため、この投稿では取り上げません。

UIテスト ユーザーインターフェイスをテストするためのものです。たとえば、ビューが意図したとおりに更新されているかどうか、またはユーザーが特定のUI要素を操作したときに特定のアクションがトリガーされるかどうかをテストできます。

各UIテストは 特定のユーザーインタラクション アプリケーションのUIを使用します。自動テストは、単体テストとUIテストの両方のレベルで実行できます。

自動テストの設定

XCodeは、ユニットとUIのテストをすぐにサポートするため、プロジェクトに追加するのは簡単で簡単です。新しいプロジェクトを作成するときは、「単体テストを含める」と「UIテストを含める」をチェックするだけです。

プロジェクトが作成されると、これら2つのオプションがオンになっていると、2つの新しいターゲットがプロジェクトに追加されます。新しいターゲット名には、名前の末尾に「Tests」または「UITests」が追加されます。

それでおしまい。プロジェクトの自動テストを作成する準備が整いました。

すでに既存のプロジェクトがあり、UIと単体テストのサポートを追加したい場合は、もう少し作業を行う必要がありますが、それも非常に簡単でシンプルです。

に移動 ファイル→新規→ターゲット 選択します iOSユニットテストバンドル ユニットテストまたは iOSUIテストバンドル UIテスト用。

押す 次 。

ターゲットオプション画面では、すべてをそのままにしておくことができます（複数のターゲットがあり、特定のターゲットのみをテストする場合は、[テストするターゲット]ドロップダウンでターゲットを選択します）。

押す 終了 。 UIテストについてこの手順を繰り返すと、既存のプロジェクトで自動テストの作成を開始する準備が整います。

ユニットテストの作成

単体テストの作成を開始する前に、それらの構造を理解する必要があります。プロジェクトに単体テストを含めると、サンプルのテストクラスが作成されます。私たちの場合、次のようになります。

理解するための最も重要な方法はsetUpです。およびtearDown。 setUpメソッドが呼び出されます 前 すべてのテスト方法、tearDownメソッドが呼び出されます 後 すべてのテスト方法。このサンプルテストクラスで定義されたテストを実行すると、メソッドは次のように実行されます。

setUp→testExample→tearDownsetUp→testPerformanceExample→tearDown

ヒント：テストは、cmd + Uを押すか、[製品]→[テスト]を選択するか、オプションメニューが表示されるまで[実行]ボタンをクリックして押したままにして、メニューから[テスト]を選択することで実行されます。

特定のテストメソッドを1つだけ実行する場合は、メソッド名の左側にあるボタンを押します（下の画像を参照）。

これで、テストを作成する準備がすべて整ったら、サンプルクラスといくつかのメソッドを追加してテストできます。

ユーザー登録を担当するクラスを追加します。ユーザーは、電子メールアドレス、パスワード、およびパスワードの確認を入力します。サンプルクラスは、入力を検証し、電子メールアドレスの可用性を確認し、ユーザー登録を試みます。

注意： この例では、 MVVM（またはModel-View-ViewModel） アーキテクチャパターン。

MVVMが使用されるのは、アプリケーションのアーキテクチャがよりクリーンでテストしやすくなるためです。

MVVMを使用すると、ビジネスロジックをプレゼンテーションロジックから簡単に分離できるため、ViewControllerの大規模な問題を回避できます。

MVVMアーキテクチャの詳細はこの記事の範囲外ですが、詳細については、 この記事 。

ユーザー登録を担当するビューモデルクラスを作成しましょう。 。

まず、いくつかのプロパティ、動的プロパティ、およびinitメソッドを追加しました。

Dynamicについて心配する必要はありませんタイプ。これはMVVMアーキテクチャの一部です。

Dynamicの場合値はtrueに設定され、ビューコントローラーはRegistrationViewModelにバインド（接続）されます登録ボタンが有効になります。 loginSuccessfulの場合trueに設定すると、接続されたビューが自動的に更新されます。

次に、パスワードと電子メール形式の有効性を確認するためのいくつかの方法を追加しましょう。

ユーザーがメールまたはパスワードフィールドに何かを入力するたびに、enableRegistrationAttemptメソッドは、電子メールとパスワードが正しい形式であるかどうかを確認し、registrationEnabledを介して登録ボタンを有効または無効にします動的プロパティ。

例を単純にするために、2つの簡単な方法を追加します。1つは電子メールの可用性を確認する方法、もう1つは指定されたユーザー名とパスワードで登録を試みる方法です。

これらの2つの方法は、NetworkServiceを使用して、電子メールが利用可能かどうかを確認し、登録を試みます。

この例を単純にするために、NetworkService実装はバックエンドAPIを使用していませんが、結果を偽造する単なるスタブです。 NetworkServiceは、プロトコルとその実装クラスとして実装されます。

NetworkServiceは、登録試行と電子メールの可用性チェックメソッドの2つのメソッドのみを含む非常に単純なプロトコルです。プロトコルの実装はNetworkServiceImplクラスです。

どちらのメソッドも、（ネットワーク要求の時間遅延を偽って）しばらく待ってから、適切なコールバックメソッドを呼び出すだけです。

ヒント：プロトコル（他のプログラミング言語ではインターフェースとも呼ばれます）を使用することをお勧めします。 「インターフェースへのプログラミングの原則」を検索すると、詳細を読むことができます。また、単体テストでどのように機能するかについても説明します。

これで、例を設定すると、このクラスのメソッドをカバーする単体テストを作成できます。

1. ビューモデルの新しいテストクラスを作成します。 TestingIOSTestsを右クリックしますプロジェクトナビゲータペインのフォルダで、[新しいファイル]→[単体テストケースクラス]を選択し、RegistrationViewModelTestsという名前を付けます。

2. testExampleを削除しますおよびtestPerformanceExample独自のテストメソッドを作成したいので、メソッド。

3. Swiftはモジュールを使用し、テストはアプリケーションのコードとは異なるモジュールにあるため、アプリケーションのモジュールを@testableとしてインポートする必要があります。 importステートメントとクラス定義の下に@testable import TestingIOSを追加します（またはアプリケーションのモジュール名）。これがないと、アプリケーションのクラスやメソッドを参照できません。

4. registrationViewModelを追加します変数。

空のテストクラスは次のようになります。

emailValidのテストを書いてみましょう方法。 testEmailValidという新しいテストメソッドを作成します。 testを追加することが重要です名前の先頭にあるキーワード。そうしないと、メソッドはテストメソッドとして認識されません。

テスト方法は次のようになります。

このテストメソッドは、アサーションメソッドXCTAssertを使用します。この場合、条件がtrueかfalseかをチェックします。

条件がfalseの場合、assertは（テストとともに）失敗し、メッセージが書き出されます。

テストで使用できるassertメソッドはたくさんあります。各assertメソッドを説明して表示すると、簡単に独自の記事を作成できるため、ここでは詳しく説明しません。

使用可能なアサートメソッドの例は次のとおりです。XCTAssertEqualObjects、XCTAssertGreaterThan、XCTAssertNil、XCTAssertTrueまたはXCTAssertThrows。

利用可能なassertメソッドの詳細を読むことができます ここに 。

ここでテストを実行すると、テストメソッドは合格します。最初のテストメソッドを正常に作成しましたが、まだプライムタイムの準備が整っていません。このテスト方法には、以下に詳述するように、まだ3つの問題（1つは大きな問題と2つの小さな問題）があります。

問題1：NetworkServiceプロトコルの実際の実装を使用しています

単体テストのコア原則の1つは、すべてのテストが外部の要因や依存関係から独立している必要があるということです。ユニットテストはアトミックである必要があります。

ある時点でサーバーからAPIメソッドを呼び出すメソッドをテストしている場合、テストはネットワークコードとサーバーの可用性に依存します。テスト時にサーバーが機能していない場合、テストは失敗するため、テストしたメソッドが機能していないと誤って非難します。

この場合、RegistrationViewModelのメソッドをテストしています。

RegistrationViewModel NetworkServiceImplに依存しますテストしたメソッドemailValidがNetworkServiceImplに依存していないことがわかっていてもクラス直接。

単体テストを作成するときは、外部の依存関係をすべて削除する必要があります。ただし、RegistrationViewModelの実装を変更せずにNetworkServiceの依存関係を削除するにはどうすればよいですか。クラス？

この問題には簡単な解決策があり、それは オブジェクトモック 。 RegistrationViewModelをよく見ると、実際にはNetworkServiceに依存していることがわかります。プロトコル。

RegistrationViewModelのとき初期化中です、NetworkServiceの実装プロトコルがRegistrationViewModelに与えられる（または注入される）オブジェクト。

この原理は コンストラクターによる依存性注入 （（ より多くの種類の依存性注入があります ）。

オンラインでの依存性注入に関する興味深い記事がたくさんあります。 objc.io 。

依存性注入を簡単でわかりやすい方法で説明する短いが興味深い記事もあります ここに 。

さらに、単一責任の原則とDIに関する優れた記事が ApeeScapeブログ 。

RegistrationViewModelのときがインスタンス化されると、コンストラクターにNetworkServiceプロトコル実装が注入されます（したがって、依存性注入の原則の名前が付けられています）。

ビューモデルクラスはプロトコルにのみ依存するため、カスタム（またはモック）の作成を妨げるものは何もありませんNetworkService実装クラスとモッククラスをビューモデルオブジェクトに挿入します。

モックを作成しましょうNetworkServiceプロトコルの実装。

TestingIOSTestsを右クリックして、新しいSwiftファイルをテストターゲットに追加します。 Project Navigatorのフォルダで、「New File」を選択し、「Swift file」を選択して、NetworkServiceMockという名前を付けます。

これは、モックされたクラスがどのように見えるかです。

この時点では、実際の実装（NetworkServiceImpl）と大差ありませんが、実際の状況では、実際のNetworkServiceImplネットワークコード、応答処理、および同様の機能があります。

私たちのモッククラスは何もしません。これがモッククラスのポイントです。それが何もしない場合は、テストに干渉しません。

テストの最初の問題を修正するために、次のように置き換えてテストメソッドを更新しましょう。

と：

問題2：テストメソッド本体でregistrationVMをインスタンス化しています

setUpがありますおよびtearDown理由のための方法。

これらのメソッドは、テストに必要なすべての必要なオブジェクトを初期化またはセットアップするために使用されます。これらのメソッドを使用して、すべてのテストメソッドで同じinitメソッドまたはsetupメソッドを記述して、コードの重複を回避する必要があります。特に特定のテストメソッドに対して本当に特定の構成がある場合は、setupメソッドとtearDownメソッドを使用しないことは必ずしも大きな問題ではありません。

RegistrationViewModelの初期化以降クラスは非常に単純です。セットアップメソッドとtearDownメソッドを使用するようにテストクラスをリファクタリングします。

RegistrationViewModelTests次のようになります。

問題3：1つのテストメソッドに複数のアサーションがあります

これは大きな問題ではありませんが、メソッドごとに1つのアサーションを持つことを提唱する人もいます。

この原則の主な理由は、エラー検出です。

1つのテストメソッドに複数のアサーションがあり、最初のアサーションが失敗した場合、テストメソッド全体が失敗としてマークされます。他のアサーションはテストされません。

このようにして、一度に1つのエラーのみを検出します。他のアサートが失敗するか成功するかはわかりません。

一度に修正できるエラーは1つだけなので、1つのメソッドに複数のアサーションがあることは必ずしも悪いことではありません。したがって、一度に1つのエラーを検出することはそれほど大きな問題ではない可能性があります。

私たちの場合、電子メール形式の有効性がテストされます。これは1つの関数にすぎないため、テストを読みやすく理解しやすくするために、すべてのアサートを1つのメソッドにグループ化する方が論理的かもしれません。

この問題は実際には大きな問題ではなく、まったく問題ではないと主張する人もいるため、テスト方法はそのままにしておきます。

独自の単体テストを作成するときは、各テスト方法でどのパスを使用するかを決定するのはあなた次第です。ほとんどの場合、テスト哲学ごとに1つの主張が理にかなっている場所と、そうでない場所があることがわかります。

非同期呼び出しを使用したメソッドのテスト

アプリケーションがどれほど単純であっても、特にUIを独自のスレッドで実行したい場合は特に、別のスレッドで非同期に実行する必要があるメソッドが存在する可能性が高くなります。

単体テストと非同期呼び出しの主な問題は、非同期呼び出しが終了するまでに時間がかかることですが、単体テストは終了するまで待機しません。単体テストは非同期ブロック内のコードが実行される前に終了するため、テストは常に同じ結果で終了します（非同期ブロックに何を書き込んでも）。

これを実証するために、checkEmailAvailabilityのテストを作成しましょう。方法。

ここでは、電子メールが利用できない（別のユーザーがすでに取得している）ことをメソッドが通知した後、registrationEnabled変数がfalseに設定されるかどうかをテストします。

このテストを実行すると、合格します。しかし、もう1つ試してみてください。アサーションを次のように変更します。

テストを再度実行すると、再度合格します。

これは、アサートがアサートされていないためです。ユニットテストは、コールバックブロックが実行される前に終了しました（モックされたネットワークサービスの実装では、戻る前に1秒間待機するように設定されていることに注意してください）。

幸い、Xcode 6では、AppleはXCTestフレームワークにテストの期待値をXCTestExpectationとして追加しました。クラス。 XCTestExpectationクラスは次のように機能します。

1. テストの開始時に、テストを設定します 期待 -テストから期待したことを説明する簡単なテキスト付き。
2. テストコードが実行された後の非同期ブロックで、期待を満たします。
3. テストの最後に、waitForExpectationWithTimerを設定する必要がありますブロック。期待が満たされたとき、またはタイマーが切れたときのいずれか早い方で実行されます。
4. これで、期待値が満たされるか、期待値タイマーが切れるまで、単体テストは終了しません。

XCTestExpectationを使用するようにテストを書き直してみましょうクラス。

ここでテストを実行すると、失敗します-当然のことです。テストに合格するように修正しましょう。アサーションを次のように変更します。

テストを再度実行して、合格することを確認します。ネットワークサービスのモック実装で遅延時間を変更して、期待タイマーが切れた場合に何が起こるかを確認できます。

コールバックなしの非同期呼び出しを使用したメソッドのテスト

サンプルプロジェクトメソッドattemptUserRegistration NetworkService.attemptRegistrationを使用します非同期で実行されるコードを含むメソッド。このメソッドは、ユーザーをバックエンドサービスに登録しようとします。

このデモアプリケーションでは、メソッドは1秒間待機してネットワーク呼び出しをシミュレートし、登録の成功を偽造します。登録が成功した場合loginSuccessful値はtrueに設定されます。この動作を検証するために単体テストを作成しましょう。

実行した場合、loginSuccessfulが原因で、このテストは失敗します。非同期networkService.attemptRegistrationまで値はtrueに設定されませんメソッドが終了しました。

モックを作成したのでNetworkServiceImplここでattemptRegistrationメソッドは、正常な登録を返す前に1秒間待機します。GrandCentralDispatch（GCD）を使用するだけで、asyncAfterを利用できます。 1秒後にアサートをチェックするメソッド。 GCDを追加した後asyncAfterテストコードは次のようになります。

注意を払っていれば、テストメソッドが実行されるため、これはまだ機能しないことがわかります 前 asyncAfterブロックが実行され、メソッドは 常に 結果として正常に合格します。幸い、XCTestExceptionがありますクラス。

XCTestExceptionを使用するようにメソッドを書き直してみましょうクラス：

RegistrationViewModelをカバーする単体テストにより、新しい機能を追加したり、既存の機能を更新したりしても、何も壊れないという確信が持てるようになりました。

重要な注意点： ユニットテストは、対象となるメソッドの機能が変更されたときに更新されない場合、その価値を失います。単体テストの作成は、アプリケーションの残りの部分についていく必要があるプロセスです。

ヒント：ライティングテストを最後まで延期しないでください。開発中にテストを作成します。このようにして、何をテストする必要があるのか​​、そして何が国境のケースであるのかをよりよく理解することができます。

UIテストの作成

すべての単体テストが完全に開発され、正常に実行された後、コードの各ユニットが正しく機能していることを確信できますが、それはアプリケーション全体が意図したとおりに機能していることを意味しますか？

そこで登場するのが統合テストであり、その中でUIテストは不可欠なコンポーネントです。

UIテストを開始する前に、テストするUI要素とインタラクション（またはユーザーストーリー）がいくつかある必要があります。簡単なビューとそのビューコントローラを作成しましょう。

1. Main.storyboardを開きます下の画像のような単純なViewControllerを作成します。

メールテキストフィールドタグを100、パスワードテキストフィールドタグを101、パスワード確認タグを102に設定します。

1. 新しいViewControllerファイルを追加しますRegistrationViewController.swiftすべてのコンセントをストーリーボードに接続します。

ここに追加していますIBOutletsおよびTextFieldTagsクラスへの構造体。

これにより、編集中のテキストフィールドを特定できるようになります。ビューモデルの動的プロパティを利用するには、ビューコントローラで動的プロパティを「バインド」する必要があります。 bindViewModelでそれを行うことができます方法：

次に、テキストフィールドのデリゲートメソッドを追加して、テキストフィールドのいずれかがいつ更新されているかを追跡します。

1. 更新AppDelegateビューコントローラを適切なビューモデルにバインドします（この手順はMVVMアーキテクチャの要件であることに注意してください）。更新されたAppDelegateコードは次のようになります。

ストーリーボードファイルとRegistrationViewControllerは本当にシンプルですが、自動化されたUIテストがどのように機能するかを示すには十分です。

すべてが正しく設定されている場合は、アプリの起動時に登録ボタンを無効にする必要があります。すべてのフィールドが入力されて有効な場合にのみ、登録ボタンを有効にする必要があります。

これを設定したら、最初のUIテストを作成できます。

UIテストでは、有効な電子メールアドレス、有効なパスワード、および有効なパスワードの確認がすべて入力された場合にのみ、[登録]ボタンが有効になるかどうかを確認する必要があります。これを設定する方法は次のとおりです。

1. TestingIOSUITests.swiftを開きますファイル。
2. testExample()を削除しますメソッドを追加し、testRegistrationButtonEnabled()を追加します方法。
3. testRegistrationButtonEnabledにカーソルを置きますあなたがそこに何かを書くつもりのような方法。
4. UIテストの記録ボタン（画面下部の赤い丸）を押します。

1. 録音ボタンを押すと、アプリケーションが起動します
2. アプリケーションが起動したら、メールテキストフィールドをタップして「 [メール保護] ’。コードがテストメソッド本体内に自動的に表示されていることがわかります。

この機能を使用してすべてのUI命令を記録できますが、簡単な命令を手動で作成する方がはるかに高速である場合があります。

これは、パスワードのテキストフィールドをタップしてメールアドレスを入力するためのレコーダーの指示の例です。 [メール保護] '

1. テストするUIインタラクションが記録されたら、停止ボタンをもう一度押して（記録を開始すると、記録ボタンのラベルが停止に変更されました）、記録を停止します。
2. UIインタラクションレコーダーを入手したら、さまざまなXCTAssertsを追加できます。アプリケーションまたはUI要素のさまざまな状態をテストします。

記録された指示は必ずしも自明であるとは限らず、テスト方法全体を読みにくく、理解しにくくすることさえあります。幸い、UI命令を手動で入力できます。

次のUI命令を手動で作成しましょう。

1. ユーザーはパスワードテキストフィールドをタップします。
2. ユーザーが「パスワード」を入力します。

UI要素を参照するには、プレースホルダー識別子を使用できます。プレースホルダー識別子は、ストーリーボードの[ユーザー補助]の下の[IDインスペクター]ペインで設定できます。パスワードテキストフィールドのユーザー補助識別子を「passwordTextField」に設定します。

パスワードUIインタラクションは、次のように記述できます。

UIインタラクションがもう1つ残っています。それは、パスワード入力の確認インタラクションです。今回は、プレースホルダーでパスワードの確認テキストフィールドを参照します。ストーリーボードに移動し、パスワードの確認テキストフィールドに「パスワードの確認」プレースホルダーを追加します。これで、ユーザーインタラクションは次のように記述できます。

これで、必要なUIインタラクションがすべて揃ったら、あとは簡単なXCTAssertを書くだけです。 （単体テストで行ったのと同じ）[登録]ボタンのisEnabledかどうかを確認します状態はtrueに設定されます。登録ボタンは、そのタイトルを使用して参照できます。ボタンのisEnabledを確認するためにアサートしますプロパティは次のようになります。

UIテスト全体は次のようになります。

テストが実行されると、Xcodeはシミュレーターを起動し、テストアプリケーションを起動します。アプリケーションが起動した後、UIインタラクション命令が1つずつ実行され、最後にアサートが正常にアサートされます。

テストを改善するために、isEnabledもテストしてみましょう。必須フィールドのいずれかが正しく入力されていない場合、登録ボタンのプロパティはfalseです。

完全なテストメソッドは次のようになります。

ヒント：UI要素を識別するための推奨される方法は、アクセシビリティ識別子を使用することです。名前、プレースホルダー、またはローカライズ可能なその他のプロパティが使用されている場合、別の言語が使用されていると要素は見つかりません。その場合、テストは失敗します。

UIテストの例は非常に単純ですが、自動化されたUIテストの威力を示しています。

Xcodeに含まれているUIテストフレームワークのすべての可能性（および多くの可能性）を発見する最良の方法は、プロジェクトでUIテストの作成を開始することです。示されているような単純なユーザーストーリーから始めて、ゆっくりとより複雑なストーリーとテストに移ります。

良いテストを書いてより良い開発者になる

私の経験から、良いテストを学び、書き込もうとすると、開発の他の側面について考えるようになります。それはあなたがより良くなるのを助けます iOS開発者 完全に。

優れたテストを作成するには、コードをより適切に整理する方法を学ぶ必要があります。

組織化されたモジュール式の適切に記述されたコードは、ストレスのないユニットおよびUIテストを成功させるための主な要件です。

場合によっては、コードが適切に編成されていないと、テストを作成できないことさえあります。

アプリケーションの構造とコードの編成について考えると、MVVM、MVP、VIPER、またはその他のそのようなパターンを使用することで、コードがより適切に構造化され、モジュール化され、テストが容易になることがわかります（Massive View Controllerの問題も回避できます）。 。

テストを作成するときは、間違いなく、ある時点で、モッククラスを作成する必要があります。依存性注入の原則とプロトコル指向のコーディング手法について考え、学ぶことができます。これらの原則を理解して使用することで、将来のプロジェクトのコード品質が大幅に向上します。

テストを書き始めると、コードを書くときにコーナーケースとエッジ条件についてもっと考えていることに気付くでしょう。これは、バグになる前に起こりうるバグを排除するのに役立ちます。メソッドの考えられる問題とネガティブな結果について考えると、ポジティブな結果をテストするだけでなく、ネガティブな結果もテストし始めます。

ご覧のとおり、単体テストはさまざまな開発の側面に影響を与える可能性があり、優れた単体テストとUIテストを作成することで、より優れた幸せな開発者になる可能性があります（バグの修正に多くの時間を費やす必要はありません）。

自動テストの作成を開始すると、最終的には自動テストのメリットがわかります。あなたがそれを自分で見るとき、あなたはその最強の支持者になるでしょう。