なぜテストですか。
ソフトウェア開発の仕事は、機能しているコードを書くことと思います。
問題は、正確さをどうやって確保できるのか
一つの方法は、コードを書いた後で、実行してみます。この方法は、小さいプロジェクトに対して効果がありますが、ある時点で機能が多すぎて追跡できません。新しいコード（フィーチャー）を追加すると、他のコードが予期せず壊れてしまいます。これは、regression（リグレックション）と呼ばれています。
より良い方法があり、自動テストです。コードで作成したコードを自動的にテストしてもらいます。自動テストは、私たちのプログラムが機能していること、そして今後も機能して続いていることを確認します。
お金や時間の節約
自動テストは、バグをより早く発現し、本番に不正な状態を展開されるのを防ぎます。
コードに自信がある
良いテストがあると、
何か壊すことを恐れことなく、コードに大きな変更を加えることができます。
金曜日の午後でも、リリースする自信があります。
より良いドキュメント
ドキュメントは、コードを更新するとフルいくなります。テストは、いつもコードによって更新しなければならないものである。
TDD（テスト駆動開発）
TDDは、テストを利用してアプリケーションの設計や開発の推進するプロセスである。
Red, Green, Refactorと呼ばれているサイクルから始めます。
Red
最初に、適用する予定のメソッドやロジックのテストを先に書きます。この時点でコードはどのように見えるかを知る必要がありません、それが何をするかを知るだけで十分です。
テストを実行すると、失敗するはずです。（テストがRed色になります）
Green
失敗するテストから、エラーメッセじを読んで、コードを書きます。この時点、テストを合格するのに十分なコードを書くだけです。コードの品質に焦点を合わせなくていいです。
Refactor
コードをクリーンニングし、複数なコードを削除する。アプリケーションのコードではなくテストコードもします。
コードに何か変更しても壊れない自信があるまでします。
TDDアプローチ
Outside-In Development
アウトサイド ・イン開発は、最初は最高レベルアブストラクション（抽象化）から始めます。というのは、ユーザがブラウザ（UI）を操作し、ページ上の要素と対話する観点である。これは、受け入れテストと呼ばれています。
受け入れテストが緑色になったら、よりコードを記述する必要はありません。
Inside-Out Development
時々、最終のソリューションがどのように見えるかわからない場合、インサイド・アウト開発はお勧めします。コンポーネントごとを構築します。
テスト駆動とテストファースト
最初にテストを書くだけで、テスト駆動と呼ばれているのは違います。
赤、緑、リファクタリングのサイクルに沿って、失敗テストに対して必要なコードのみを記述することは重要です。これにより、ソリューションのスコープ外の設計、テストされていない機能を実装しなくなります。
また、リファクタリングのスッテプをスキップしないことも重要です。これは、TDDの最も重要な部分の一つであります、コードを保守しやすく、将来変更しやすいくようにします。
TDDの利点
- Confidence（自信）
- Time Savings（時間節約）
- Flow（フロー）
- Improved Design（設計の改善）
TDDしない時（実用的）
- アプリケーションが小さい、変更が少ない（ほとんどない）
- 短い時間で利用するつもりであるプログラム
- アプリケーションの重要性が低い、壊れても影響がない
効果的なテストスイートの特性
- 速度 (speed)
- 完成度 (complete)
- 信頼性ある (reliable)
- 孤立 (isolated)
- 保守可能 (maintainable)
テストタイプ
テストパイラミッド
Refs
testing-rails/testing-rails.md at master · thoughtbot/testing-rails · GitHub