レガシーコードからの脱却 10.1 – 10.1.3

10.1 テストと呼ばれるもの

内容

テスト駆動開発の話の前に、一般的なテストの種類と目的を理解しようという前置き。

10.1.1 受け入れテスト=顧客テスト

受け入れテスト、あるいは顧客テストはストーリーのふるまいを明確にするもの。受け入れ基準を定義することで、受け入れテストがどうなったら終わりになるか明確になる。それにより、

• 開発者が特定のエッジケースや例外のシナリオの理解に役立つ
• 開発者がどうなれば正解か理解しきれずに進めてしまい、作り過ぎてしまうことを防止する

などの効果がある。これにより開発者は安心して進む事が出来る。
受け入れテストツールにGherkinという自動化ツールがあることの紹介。
受け入れテスト駆動開発に関する書籍2冊紹介。

• Lean-Agile Acceptance Test-Driven-Development
• Specification by Example

10.1.2 ユニットテスト＝開発者によるテスト

ユニットテストの概要が書いてある。

• ストーリーよりも小さいテスト
• 開発者がテスト駆動開発で作るテストコードによるテスト
• ドキュメントとしても機能する
• 将来の変更時のミスを見つけるための回帰テストにもなる

10.1.3 それ以外のテスト＝QAテスト

ワークフロー中のコンポーネント間の相互作用をテストする結合テストのように、QAプロセスの「一部」になる。
結合テストは、モックではない実際の依存関係を使用してコンポーネント間の相互作用をテストする。
そのためユニットテストより多くの依存関係をビルドするのでビルド時間がかかる。

機能をテストするために、ユーザーの入力をシミュレーションするツールを使うこともあるが、これがテストの唯一の方法なら、考慮すべき設計上の制約があるかもしれない。できるかどうかはさておき、簡単に検証できるようにテスト可能なコードを書くことを追求すべき。

テストを2つのカテゴリに分類するとする。

• リリース候補を検証するために必要なテスト
• そのほかすべて

これらはできるだけ多く自動化することが重要だが、リリース候補のテストをすべて自動化することはさらに重要。
人間を介入させると、外部への依存性が生まれ、うまくいかないことがあるからだ。
問題が起きる可能性を最小限にするために、できるだけ依存関係を少なくなるようにするが、ソフトウェア開発プロセスも依存関係を少なくすることが必要だ。
GPSなどの機能は人間によるテストが必要なケースだが、そういう場合はコンポーネントを切り分けて必要なところだけを人間に任せる。

学び

• 受け入れテストはストーリーの振る舞いを明確にするものであり、これが要件である。
• これを基準にテストの増えすぎや実装の増えすぎを抑えることができる。

• テストスイートの意味。テストの集合。
• 上記「内容」

• 結合テストの定義について明確になった。モックではなく実際の依存関係を使い、コンポーネント間の相互作用をテストする。
• 問題を減らすためにソフトウェア開発プロセスにおける依存関係も減らす。
• 人間を介入させると外部への依存関係が増える。

学びを活かすアイディア・行動

• テストコードの目的の前提知識整理
• 受け入れテスト自動化の学習
• 現場のテストコードのコーディング規約づくり