レガシーコードからの脱却 まとめ – 10.2 – 10.2.2
10.2 QA 内容 QAテストの種類・形態を紹介。 コンポーネントテストユニットがどのように連携するかを調べる 機能テストユニットを機能ごとにまとめてEnd to End（端から端まで）のふるまいが完全かを調べる シナリオテストユーザーがシステムを使って、実際に使えるかを調べる パフォーマンステスト何百万ものアクセスに耐えうるか調べる セキュリティテストコードの脆弱性を探す プロジェクトに必要なテストはリスクによって異なる。たとえばペースメーカーとソーシャルメディアのアプリケーションではテストの方法は変える必要がある。Google、マイクロソフト、Amazonは品質担当はQAの自動テストを作れる人たちにして成果を上げている。 10.2.1 テスト駆動開発はQAの代わりではない ふるまいを「検証」ではなく「表す」方法としてテストファースト開発（TDD）を行うと、どんなテストが必要かがより明確に理解でき、無駄がなく意味のあるテストの土台が手に入る。これは安心してコードをきれいにするのに役立つ。 しかし、これ自体がQA作業を置き換えるわけではないと言っている。セキュリティ関連のテストをしなくてよいわけでもないし、パフォーマンス関連のテストをしなくてよいわけではない。 10.2.2 ユニットテストは万能ではない 基本的に、ユニットテストはテストファーストで作れば、良い設計の手助けとなる。 しかし、ユニットテストではなくEnd to Endテストで確認したいものもある。たとえば、UIとのやりとり、DBとのやりとり、マルチスレッド、高度なコード、などだが、これらはテスト駆動開発を使用せずに書かれていて、テストのないコードになっておりテストが困難な場合が多い。 設計を変更して構わないなら本質的にテストできない機能はないが、設計を変更できないときもある。（既存のコードとやり取りしている場合、既存のパッケージを使用している場合など。） そういうわけで、ユニットテストはテストファーストで進めば、良い設計の手助けとなるが、万能ではない。 学び テストの種類と目的の理解が深まった 自身のプロダクトはどんなテストが必要か、こういったテストの種類を知った上で考える必要がある テスト駆動開発はパフォーマンステスト、セキュリティテストなどのQAをするのは難しい。（費用対効果が薄い） テストファーストでユニットテストを作れば良い設計の手助けになる UI、DB、マルチスレッド、高度なコードなどはテストが難しい（観測が難しい） 学びを活かすアイディア・行動 テストコードの目的の事前知識整理 現場でのテストコードの運用範囲を決める。 テストコードのコーディング規約づくり（テスト運用の注意点）