テスト自動化について学ぶ前に、「ソフトウェアテスト」全体について知っておかないといけない。全体のどこが自動化できるか？という話になると思うから。
変更しやすさ・品質維持のしやすさ(テストしやすさ)から逆算したアーキテクチャ、設計が絶対に必要なんだと思う。
キーワード：テスタビリティ
テスト自動化も、DDD等と同じく、変更しやすさ・品質維持のしやすさを向上するための道具の1つに過ぎない。
テスト自動化が流行しているのは、アジャイル開発の流行、それによるDDDの流行が背景にあると思う。
自分の経験として、JUnitをうまく扱えているプロジェクトはなかった。途中でJUnit組むのをやめているか、ただ組んでいるだけ。
テスト戦略の観点から、テスト自動化の意義を理解できているプロジェクトはほぼない。
テスト自動化（＝JUnit組む）によって欲しい結果は…
・単調なテストを手動でやる時間を減らせること
・デグレ防止
どうしても、結局は手で動かす必要はある。ただ、すべてを手で動かす必要はない。
手で動かす部分と、自動テストでやっていい部分の切り分けが第一。
そりゃあ、テストが仕様を表すようになるのが理想なのはわかる。テストは「期待」通りに動くことを確認するもの。期待＝「仕様」だから。
自動テストも人が書くものだから、人以上のことはできない。
人が書くものだから、自動テストコード自体が間違っていることがある。でもそれは、手動テストでも同じ。手動テスト自体が間違っていることがある。だから、そのことが自動テストをやらない理由にはならない。
なぜ私が自動テストをやる気にならないか、現場でやらない方向に倒したくなるか。それは、自動テストをやる決定的なメリットを感じないから。
自動テストもやって、手動テストもやる。と言われただけじゃあ私は動かない。
ここは手動で、ここは自動で。って言ってくれたら喜んで動く。その体系が今の私にはない。