テスト駆動開発 - ntuf/Tips GitHub Wiki

『iOSアプリ開発自動テストの教科書』からの抜粋と要約

バグを見つけるのが自動テストの主たる目的ではなくて、
（既に見つかっている場合が多い）
問題なく動いていたはずの機能が動かなくなっていることを確認するためのもの

・自動テストのメリット
　・人より早い
　・属人性が排除される
　・繰り返す際はコストが軽減できる
　・守りながらリファクタリングできる

Mike Cohnのテストピラミッド
UIテスト（上層）
結合テスト(中層)
単体テスト（下層）

・下の層のテストの数が最も多く、上に行くほど数が少なくなる方が良い
・自動テストで全てを担保することは現実的ではない。
　が、テストの自動化を導入することによって削減できる工数に見合うかどうかで、
　画一的な答えはない。
　　例
　　　ログイン機能
　　　　正しく動かないとユーザが多大な不便を強いる
　　　　ユーザ種別ごとにUIテストを作成する
　　　プレミアム登録機能
　　　　入力値の検証は単体テストで網羅的にテストする
　　　　基本的な導線だけをUIテストを実装
　　　　難しい場合は実装を妥協する
　　　検索機能
　　　　膨大な組み合わせになるために手動テストには多くの工数がかかる
　　　　高速で実行できる単体テストを実装する

★単体テストの目的
粒度の小さいテスト、網羅的なテストに有効。
高速で、繰り返し可能な自動テストを

例
　ショッピングアプリ検索機能
　　UIテストの場合は画面デザインに変更があった場合、ほとんどのケースではテストを修正しないと動作しない
　　単体テストで結合テストを行った方が良い。

単体テストの範囲？
　MVCアーキテクチャを範囲で言うと、
　ViewControllerや、Viewだけをテストするためには
　Modelに依存してしまうことになるが、モックという手法で
　Modelをテスト用の偽物のコードに置き換えViewControllerのみをテストする
　いくつかのクラスを結合した方が費用対価が高い場合もある。（これは結合テスト）

★UIテストの目的
手動と同じようなテスト可能だが、
多用はしない。
デメリットを知った上で効果的にUIテストを導入する

　・UIテストのデメリット
　　　・手動テストを完全に置き換えることはできない
　　　　手動テストだと、レイアウトの崩れにすぐ気がつく。
　　　・UIが変わった場合はテストを修正する必要がある。
　　　　修正工ストがかかる。
　　　・実行時間がかかる
　　
■テストの失敗原因をわかりやすくする

・メソッド名をわかりやすくする
例
加算メソッドの例
　add()
　　①対象メソッド名のみのパターン
　　　testAdd()
　　　　→どんなテストかわからないが、正常系のテストが一つだけとかの場合はこれでいい場合も。
　　②情報を全て記載したパターン
　　　testAddWhenSet2And3ShouldReturn5()
　　　　→詳細がわかるが、値を少しでも変えるとテストケース名まで変える必要がある。
　　③条件と結果を指定したパターン
　　　testAddPositiveNumberReturnPositiveNumber()
　　　　→詳細がわからないが何が返ってくるかまではわかる
　　④条件を指定したパターン
　　　testAddWithPositiveNumber()
　　　　→期待値まではわかるが、事前条件まではわからない
・中身をわかりやすくする
　４つを分けて実装しようとする考え方(Four-Phase Test)
　　前処理
　　実行
　　検証
　　後処理
　
■自動テストをどこから追加するか
・単体テストの自動化のタイミング
　　新機能の開発時
　　リファクタリング
　できるだけ単体テストから追加していくのが望ましい。

■不安定なテストは
２回動かせば1回は成功するというようなテスト
　・テストをなおす
　　　すぐに対応できれば問題ないが
　　　原因が特定できない等の場合は状況によって判断する
　・置き換える
　　　上部のテストになるほど、テストが不安定になる
　　　手動テストかUIテストで置き換える
　・テストケース自体を削除する
　　　残っている場合に問題があることもあるので、
　　　置き換えも検討しつつ削除も考える。
　　　
■テストの実行時間を減らす方法
　・ピラミッド下部で対応する
　・不必要なテストケースでは作らない
　・テストの実行を並列化する

■疑問点
XcodeでUIテストで＼ってどうやってじっどうするんだ？