初めての自動テスト ―Webシステムのための自動テスト基礎

アジャイル開発に絶対必須の自動テスト。そのとっかかりになりそうな本です。

いわゆる「テストピラミッド」をベースに話が進んでいく。

第1部　ピラミッドの地図を作る

美しいテストを作ったのに壊れた話。
ユニットテストの代わりにUIテスト→重くなる→エラーが見つけづらくなる、テスト実行を嫌がりだす→壊れたまま作り続ける→崩壊…

3つの教訓

UIテスト（Cypressなど）は、アプリケーションを全体通して見てくれていい感じに見えるけど、コストが高い（重い＆壊れやすい）

統合テストは、UIを通過しないのでUIが壊れていても通せる　が、どこが壊れてるかは分かりづらい

ユニットテストは、とにかく速く、どこがだめだったかすぐわかる。ただし、つながりの部分については弱い

まずユニットテストを書いて、そこから統合→UIと進めていこう。

ユニットテストは開発のため、UIテストは検証のためのもの。

自動テストの作成を誰が行うか？開発者とテスターは立場が違い、重視するところが違う

→協調して行おう。テスターも自動テストを書こう、開発者もテスターの生産性を上げよう。

UIテストの仕組み：HTMLとCSSのタグを使って要素を取得し、アサーションを入れよう

既存のHTML、CSSを使用して要素を取得する方法を学ぶ。

UIがなくても、リクエストを作成する方法がわかれば統合テストが作成できる。

GET、POST、PUT、DELETEをリクエストを作成してテストする。

ユニットテストは非常に高速。ただ、局所的なものなのでネットワークが絡むところは避けたほうがいい。

モック化大事！

ブラウザで起きていることをユニットテストで確認することができる。UIテスト＝E2Eではない。

３種類のテストの得意分野で勝負する。

マジの初級講座なので割愛。

テストを全部同じとこにまとめると後で大変なので、整理することが必要。

必ずしもモックを使う必要はない。現物が使えるならそれで良し。

使いやすいものではあるけど、頼りすぎないようにする。

TDD（テスト駆動開発）について。銀の弾丸ではないので、自分でしっかりコードを書こう。

テストは大事だけど、やみくもにやってても壊れやすいテストになり、維持できなくなってしまう。

ユニットテスト、統合テスト、UIテストのそれぞれの特性を知り、適切に組み立てよう。