「初めての自動テスト」読書メモ

どんな本か？

なぜテストを書くべきか、ということよりもどうやってテストを書けば良いかについてわかりやすく記載している本。非常に読みやすく、全体にざっと目を通すのにあまり時間はかからない。テストを書いたことがない人も、テストを書いたことはあるが体系的に学べていない人にも、とても参考になる内容と感じた。ちなみに自分はこれまである程度はテストを書いてきたが、ユニットテストと統合テストのどちらを優先すべきか、それはなぜか、といったことや、モックをどのような場面で活用すべきか、といった点についてきちんと理解できていなかったが、この本を読みすすめていく中で、答えをある程度見つけられた気がする。以降は、読んでいく中で自分がメモを取っていた内容。断片的な情報なので、内容が気になった方は是非一度読んでみていただければと思う。

各章の読書メモ

1章

• 優先順位はUI < 統合 < ユニットテストの順（テストのピラミッド）
• E2Eテストは遅く壊れやすいため、素早いフィードバックを得るという点で劣っている
• 上の階層であればあるほど、「何か」が壊れていることは分かっても、厳密に「どこ」が壊れているかがわからない
• テストケースの実行に長い時間がかかるほど、開発サ イクルは遅く、反復回数は少なくなる。

2章

• 要素の位置に依存するUIテストを書いてしまうと、ページのレイアウトが変更された時にテストが壊れる

3章

• UIテストは脆弱になりがち、UIに対して密結合にすればするほどテストは壊れやすくなる
• コツはテストをゆるく書くこと＝詳細に結びつけすぎない

4章

• 統合テストが重要な理由＝UIテストでは見つけにくい下位レベルの不具合、しかもユニットテストのレベルでは見落としてしまうものを発見

6章

• エッジケースについては特にテストする
• ユニットテストではネットワークに直接接続することを避け、代わりに準備済みのテストデータを使う
• モック化＝テストしたいコードにおいてアクセス困難な場所もテストできるようにするための技術

7章

• UI自体のテストをするなら、必ずしもE2Eでないといけないとは限らない

8章

• 統合テストでは、壊れる可能性のあるものを全てテストすることは目指さない
• システムに対してUIテストが1件もなくても気にする必要はない

10章

• データは可能な限り、そのデータを使っているテストに近いところにまとめる

11章

• 遅かったり不安定だったりするサービスはモック化するのに向いている
• スタブ＝ハードコードされたデータを返すテストダブル、基本的にロジックを持たない
• 全ての処理をモック化する必要はない。その方がテストの意図が明確になる
• モックの泥沼＝ユニットテストのコードがモックに埋め尽くされてしまい、元々のテストがほとんど意味をなさなくなる
• 単純にユニットテストで扱いたくない部分、つまり外部に接続する部分だけをモック化する。例えば音楽ストリーミングサービス

12章

• TDDのメリットは以下
  • オーバーエンジニアリングを防ぐ
  • コードの設計が改善される
  • 複雑な内容を扱いやすい
  • 単純に楽しい
  • テストしやすいコードが書ける