テストの目的

開発を加速させる
潜在的なバグや境界値に潜む問題をあぶりだすことができる

テストの原則

テストは信頼できるものであること
テストは簡単に書けること
テストは簡単に理解できること
スピードを重視しないこと
テストの中では過度にDRYなコードを目指さないこと

TDD(テスト駆動開発)とは

chatspaceでは、開発環境のモデル、コントローラーを書き終えてから、テストを書きました。果たしてこれは正しい順序なのでしょうか？
ここではTDD(テスト駆動開発)というものを紹介します。

TDD(テスト駆動開発とは)

プログラム開発手法の一種で、プログラムに必要な各機能について、最初にテストを書き（これをテストファーストと言う）、そのテストが動作する必要最低限な実装をとりあえず行った後、コードを洗練させる、という短い工程を繰り返すスタイルである。
(wikipedia参照)

TDDの手順

1.プロダクトコードを書く前にテストコードを書き、それが失敗することを確認する (レッド)
2.テストに成功するようにプロダクトコードを書く (グリーン)
3.プログラムの振る舞いを変えないように、プロダクトコードの重複などを整理する (リファクタリング)
(最初に戻る)

TDDの主な目的

テストを最初に書くことで、自分が作るべきプログラムが明確化されるとともに、実行工数を15％から25％増加させる代わりに、欠陥密度を4割から9割低下させてデバッグや手戻り工数を減少させ、トータルの総工数を削減する事が出来る。
他にも以下のようなメリットがあると言われている。
・テストコードが必ず作成される。
・実装前に仕様を決めることでメンバーが仕様を明確に把握した状態で開発に取りかかれる。
・仕様齟齬に気づくタイミングが早い。

テストの重要なテクニック

期待する結果は能動形で明示的に記述すること
起きてほしいことと、起きてほしくないことをテストすること
境界値テストをすること
可読性を上げるためにスペックを整理すること
- describe
- context
- before →次のカリキュラムで解説します。

Q＆A

モデルに含まれる全てのバリデーションを確認しようとしたらどれくらい大変になるのかわかっているのか？

実際自分が考えている以上にバリデーションは書き忘れやすものです。しかし、それよりもっと大事なことは、テストを書いている最中にモデルが持つべきバリデーションについて考えれば、バリデーションの追加を忘れにくくなるということです。このプロセスはテスト駆動開発でコードを書くのが理想的だし、最後は実際にそうします。

どれくらい DRY だと DRY すぎるのか？

example のテスト条件をセットアップする際、可読性を考えて DRY 原則に違反するのは問題ないです。もし自分がテストしている内容を確認するために、大きなスペックファイルを頻繁にスクロールしているようなら、テストデータのセットアップを小さなdescribeブロックの中で重複させることを検討してください。describeブロックの中だけでなく、example の中でも OK です。

なぜテストをするのか？

目次