どうも、えんつかです。
今までテストに少し触れていただけというのもあったので、全体像・概要とか学びつつ、今後の業務でのテスト導入に向けて予習しました!
本記事は、オライリー・ジャパンさんの初めての自動テストを読んでの私なりのまとめです!!
主に、「テストの全体像について」「大切そうだと思ったこと」を私なりに記載していきます!
テストとは?と言った方や、これからテストを触ろうとする方の参考になると思います!
【テスト】初めての自動テスト【概要】
テストは、私が思っていたよりも色々あることがわかりました。思い込みは危険!
テスト全体像
テストは、作成したプログラムが意図した通りに動作するのかを確認することです。
テストの方法には大きく分けて以下の3種類があります。
- UIテスト
- 統合テスト
- 単体(ユニット)テスト
UIテストは、ユーザーがそのシステムを実際に使用する時の様に利用して確認するテストです。
統合テストは、UIを利用せず、様々な層がつながっていることを確認するテストです。この様々な層とはとても抽象的なんですが、イメージとしてはステータスコードで、サーバーとのやり取りなどをイメージしてもらえればOKと思います。
単体(ユニット)テストは、ソフトウェアが正しく動いていることを確認するために開発者が作成するものです。正しく動いていることを確認とは、小さいレベルで確認することができ、システムが想定する前提条件をテストすることができます。
もう少し、各テストについて深掘っていきましょう!
UIテストについて
UIテストはアプリをユーザーが操作するのと同じ様にテストするもので、クリック、選択、ログイン等が問題なく動作するのか直感的に確認・理解できます。
UIテストの特徴は次の通り。
- UI側から裏側までの動作を確認できる
- ユーザーと同じ対象をみれる
- 高コストで遅い
UIテストはアーキテクチャの全ての層を通過し、全ての層がつながっていることを確認できます。その為、エンドツーエンドで動くテストとも呼ばれる様です。エンドツーエンドはとても良いことなのですが、一方問題なのはスピードが遅いのと壊れやすいと言う点がある様です。
確かに、文言の修正だったり、CSSの微小修正とかが入るとまたテストを修正しないといけないですもんね。なので、より詳細にUIに対して密結合にすればする程テストは壊れやすくなります。UIテストを書く時は、なるべく疎結合に詳細になりすぎない様にするのがポイントの様です。コツは「緩く」だけど「緩すぎない」とのことです。
統合テストについて
統合テストは、アプリを動かすサービスをテストするもので、具体的にはWEBサーバー上で動作し、HTTPのリクエストに対してレスポンスを返すプログラムのことを指します。
統合テストの特徴は次の通り
- WEBサービスとAPIのテスト
- つながりを確認できる
- 詳細さに欠ける
何が壊れていることはわかっても、厳密にどこが壊れているかまではわからないのが、唯一の欠点の様です。
具体的には、HTTPのステータスコードがテストすべき対象で、HTTP GETのリクエストに対して、返ってくるステータスコード(200, 302, 404)が狙ったものなのかをチェックしたりします。
ユニットテスト
ユニットテストは、ソフトウェアが正しく動いているか確認するための、メソッドレベルが小さいテストです。枝葉で言うと葉の様な細かい部分を見るのがユニットテストです。それにより、高速に実行できて手軽に使える特徴があります。また、ユニットテストは何に対しても書くことができるので、システムが想定している前提条件をテストすることも可能の様です。
なので特徴は次の通り
- 高速で実行可能
- 多目的利用が可能
- 統合部分の確認に弱い
ユニットテストを書く時に考慮すべき内容は次の通り
- ハッピーパス:意図した動作が起きたとしてメソッドはどう動作するか
- 特殊ケース:注意を払うべき特殊条件
- 例外:例外が起きたときにメソッドはエラーを起こせるか
- プログラムのロジックと流れ:ロジック、パス、条件分岐は適切に動作するか
- その他何でも:メソッドが正しく動くことに自信を保つためにどんなテストを行う必要があるか
テストのピラミッド
これらのテスト(UI、統合、ユニット)がどの様に補完しあうのかを示したモデルが、テストのピラミッドと呼ばれ、一番上にUIテスト、その下に、統合テスト、一番下にユニットテストと言った、ピラミッドの様に下に行くほど裾野を広げるイメージになります。
現場の状況次第で適切に判断するべきで、一概に全て当てはまるとは思っていませんが、本書が進めるテストの法則で「親指の法則」と言うのがありました。
- UIよりもユニットテストを優先すること
- ユニットテストで埋められない部分を統合テストでカバーする
- UIテストは限定的に利用
- 新しいテストを追加する時はユニットテストでカバーできないかを最初に確認
- テストはできる限りピラミッドの下の層にいれる
- 全てを自動化しようとしないこと
リソースが十分にあり、こう言った部分にも配慮できる余裕があれば、利用してみるのもありかも知れませんね!
以上!
また、色々アウトプットしていきます!