初めての自動テストのまとめと書評・感想

英タイトルは「The Way of the Web Test ~A beginner’s Guid to Automating Tests~」である。

テストのピラミッド

UIテスト	システム全体をE2Eで操作するテスト。 UIからプレゼン層、ビジネス層、データ層までアーキテクチャの全層を対象とする。低速であり、遅い。壊れやすい。
統合テスト	フロントを除く、API全体を疎通させるテスト。 API全体が繋がって動いていることを確認する。
ユニットテスト	メソッド単位、クラス単位など、最小単位のテスト。高速である。厳密に「どこ」が壊れているかわかる。

ピラミッドの各層の概要

1.UIよりもユニットテストを優先すること
2.ユニットテストで埋められない部分を統合テストでカバーすること
3.UIテストは限定的に使うこと
1翔　テストのピラミッド

ユニットテストが適切に組まれているとどんなメリットがあるか。

クラスのpublicメソッド単位でテストケースを作成する。

次の観点で確認するためのコードを書くと良い。

GETメソッド、主にデータ取得処理のテストコードはこうなる。

POSTメソッド、主にデータ登録・追加処理のテストコードはこうなる。

主にデータ更新・編集処理のテストコードはこうなる。

ソフトウェアの主要な機能が常に稼働していること（システムの持続性）を保証すること。
- アプリケーションが適切にデプロイされていること。
- 環境が適切に設定されていること。
- パーツが正しく接続されていること。

ログインの手順を自動化すると、こんな流れになる。

これによって、UI〜サーバサイドの全層が正常に稼働していることが確認できる。

HTMLのid属性による選択をするのが良い。
HTML要素の存在をチェックするときは、値と完全に一致することを確認する必要はない。
- メッセージをチェックする場合、メッセージに使用するclass属性があれば、class属性の属性値が合っていれば良い。メッセージの中身まで合っているか確認しなくて良い。
- UIテストは脆弱で壊れやすいため、詳細な確認になり過ぎないよう気をつける。

テストコードの中で通過するコードが重複している部分がある。無駄ではないか？
＞テストの意図が重複していなければ、コードが重複していることは全く問題ない。

キャプチャーリプレイ（自動記録と再生）ソフトを使ってUIテストを組むのはどうか？
＞大抵はうまくいかない。UIのほんの一部を変更下だけでテストが壊れる。ソフトが生成したテストコードは人間にとって読みにくい物になりやすく、可読性が下がる。

コードカバレッジの目安は？
＞優れたチームは、たいていカバレッジ70%~80%くらいのどこかに落ち着きます。

平易な文章ですらすら読み進められ、3時間ほどで読了できた。
自動テストについて体系的に俯瞰したいという点では物足りなかった。
実践的な内容になっているかという点でも物足りなかった。

テストをしない人が自動テストっておおよそこんなものって知るための読み物にはいいかなと思いましたが、実案件で使えるレベルの知識が欲しい人は他の同ジャンルの本を読む必要があると思います。