Note to Self

自分用のメモ置き場

【読書メモ】初めての自動テスト -Webシステムのための自動テスト基礎

読書メモ

O'Reilly Japanの「初めての自動テスト -Webシステムのための自動テスト基礎」を読んだ際のメモ。

ざっくりと自動テストについて知りたい場合はいいと思う。

1章 テストのピラミッド

  • 典型的な自動テストにはUIテスト、統合テスト、ユニットテストの3種類がある。
  • 新しいテストを追加するときには、まずユニットテストで対応できないかどうかを確認する。
  • テストは、常にピラミッドのなるべく下の層に入れるようにする。
  • ピラミッドのすべての層において、チームメンバーと協力し、無駄や重複を避ける。

2章 ユーザーインターフェイステストに触れる

  • UIテストはエンドツーエンドのスモークテストとして有用である。
  • キャプチャーリプレイのスクリプトよりも手で書いたテストコードの方が望ましい。
  • テストでアサーションを入れるときには HTMLのタグを対象にする。
  • ページの要素を選択するときには CSS セレクタを使う。
  • HTMLのIDが付いている要素は取得しやすい。

4章 統合テストで点と点を結ぶ

  • ブラウザ上の操作は最終的にはすべてWeb のリクエストに変換される。
  • RESTとは、HTTPの4種類の動きでリソースを操作するWebサービスの設計方式のことである。
  • Webの世界は多くのURLで構成されており、URLを使ってテストを駆動することができる。

5章 RESTfulなWebサービスの統合テスト

  • RESTfulなサービスをテストするにはまず正しいURLを生成し、適切なHTTPのメソッド とデータを送信する。
  • HTTPのステータスコードは、サーバーがHTTPリクエストの成否を伝えるための仕組みである。
  • ブラウザのデベロッパーツールを使って、いつでもネットワークトラフィックを調べられる。
  • HTTPのGETリクエストは、ブラウザを開いてアドレスバーにURLを入力するだけで確認 できる。

6章 ユニットテストで基礎を固める

  • ユニットテストはテストのピラミッドの基盤となっており、他の階層に比べて多くのテストを担っている。
  • ユニットテストは非常に高速に実行できるため、迅速なフィードバックを得られる。
  • ユニットテストはきわめて局所的に書くことが多く、ネットワークに接続するような処理は避けた方が良い。
  • モック化は、テストしたいコードにおいてアクセス困難な箇所もテストできるようにするための技術である。

7章 JavaScriptを使ったブラウザ上のユニットテスト

  • ブラウザ上で起きていることをユニットテストで確認できる。
  • UIテストは必ずしもエンドツーエンドである必要はない。
  • JavaScriptは静的型付け言語ではないので、キーボードのタイプミスには十分注意しなければならない。

8章 ピラミッドを登る

  • テストの大部分をピラミッドのユニットテストのレベルで行う。
  • 統合テストのレベルでは、なるべく多くの接続のテストを行い、ユニットテストで捉えきれない溝を埋める。
  • UIテストは限定的に使う。 UIテストで詳細を見ることにコストをかけるべきではない。

10章 テストを整理する～混沌の中から法則を見つけ出す～

  • テストの対象を絞り、分離すること。 1度に多くの内容をテストしようとしないこと。
  • 似ているテストをコンテキストによってまとめ、頭を使わなくても理解できるようにしておくこと。

11章 効果的なモックの活用

  • ユニットテストでは、必ずしもモックを使う必要はなく、代わりに本物のオブジェクトを使っても良い(可能なら使うべきである)。
  • ユニットテストの対象は、オブジェクトのパブリックAPIに絞って外側からテストすることで結合度を下げ、オブジェクトの設計変更をしやすくする。
  • モックは手頃なツールだが、使いすぎないようにする。 少し変わった実装しづらいシナリオ を扱うのには向いているが、乱用して泥沼にはまるのは避けたい。
  • ユニットテストでは、可能な限りオブジェクト内部の機構ではなく外に向けた振る舞いにフォーカスすること。
  • 結合が大きな問題になることがある。
  • システムをより外側からテストすることができれば、テストも設計も保守、変更しやすくなる。

12章 テストファースト
テスト駆動開発(TDD)とは、プロダクションコードを追加するよりも前にテストを書くいうプラクティス。

  • テストファーストは、テストと同じくらい設計にも重点を置いている。
  • 常に失敗するテストを書くところからスタートし、そのテストを成功させ、それからリファクタリングする。
  • 行き詰まってしまったとき、1度に1つのテストに集中して仕上げたいときには、TDDは最適な手法になる。
  • TDDは銀の弾丸ではない。 TDDが魔法のように完璧なコードや素晴らしい設計を与えてくれるわけではなく、設計やコーディングは自分で行わなくてはいけない。
  • TDDは数多くあるサポートツールの1つであり、良いコードを書けるかどうかはあなた次第である。