開発者がテストを通じて開発の喜びを初めて発見するとき、それはストレスと不安がはるかに少ない新しい、より良い世界に移動するようなものです。 この素晴らしい体験は本当に称賛に値します。 しかし、テストの利点を理解することは、啓発への第一歩にすぎません。 最も難しいのは、テストする必要がないことを理解することです。
初心者が1日目にテストする価値がないことを心配する必要がない場合は、2日目に掘り下げてみるとよいでしょう。 人々は習慣を構築しているので、最初から過剰なテストの悪い習慣を形成し始めると、後でそれを取り除くことははるかに困難になります。 そして、あなたはこの習慣を取り除く必要があります。
「 しかし、オーバーテストの何が問題なのか、フィル、あなたはあなたのコードを安全にしたくないのですか？ 本番に入る前に別のバグを見つけた場合、それだけの価値はありませんか？ 「ああ、それは価値がない、そして私をフィルと呼んではいけない。 このような推論のために、TSAを入手し、それらがどのように数十億を合併して卵を感じ、ニッパーを没収するかを取得しました。
翻訳者注：TSA-Transportation Security Administration-米国運輸保安局。検索中（特に空港で）の驚異的な緻密さのために彼らは非常に嫌いです。
テストは無料ではありません。
記述するコードの各行には価格があります。 それを書くのに時間がかかり、それを更新するのに時間がかかり、それを読んで理解するのに時間がかかります。 したがって、それを書くことの利点は、その価値以上のものでなければなりません。 オーバーテストの場合、これは間違いです。
このように考えてください：バグを防ぐための価格はいくらですか？ ボブが誤って「 validates_presence_of：name 」という行を削除するのをキャッチするために1000行のテストを書く必要がある場合、それは価値がありますか？ 当然、そうではありません（はい、はい、火星へのミサイル発射制御システムに取り組んでおり、ロケットがホワイトハウスに飛ぶ場合、名前を付けるのを忘れた場合、テストできます-しかし、これはあなたの場合ではありませんので、忘れてください）。
過剰なテストを特定する際の問題は、このためのキャッチーな用語を見つけるのが難しいということです。 テストファースト（テストファースト）、レッドグリーン（レッドグリーン）、またはステージ中央の適切な場所へのテストを通じて開発を推進する他のセクシーな用語ほどコンパクトなものはありません。 必要なものだけをテストするには、微妙なアプローチ、経験、およびかなりの直感が必要です。
7つの「NOT」テスト
繊細な点はすべて、啓発された対談者との2時間の夕食で簡単に説明できますが、このためのポストには十分なスペースがありません。 したがって、fireを議論の火に投げ込みましょう-典型的なRailsアプリケーションをテストする方法について微妙なことなく意見のリストを提供します：
- 100％のテストカバレッジを目指して努力しないでください。
- 1対2を超えるコードとテストの比率はすでに匂いがあり、1対3を超えている-悪臭を放ちます。
- テストに時間が3分の1以上かかる場合は、おそらく間違っていると思われます。 テストに時間が半分以上かかる場合、間違いを犯しています。
- 標準の関連付け、検証、ActiveRecordミサゴをテストしないでください。
- 個々の要素を結合するときに発生する問題の統合テストを保存します（つまり、単体テストを使用できるものについては統合テストを使用しません）。
- プログラマーテスト以外の作家の魔法の王国に住んでいない限り、キュウリを使用しないでください（または、まだそこにいるなら魔法の粉のボトルを送ってください！）;
- 各コントローラー、モデル、またはテンプレートに対して最初にテストを書くように強制しないでください（私の通常の比率は、最初にテストの20％、その後にテストの80％です）。
テストを通じて開発の適用を開始する方法に関するこれらの数百冊の本すべてを考えると、この獣を後で飼いならす方法について1つか2つの本が欲しいと思います。 テストする価値のあるものとそうでないものを決定する際に微妙な点がたくさんありますが、誰もがテスト方法の同じ例に焦点を合わせると、それらはすべて失われます。
しかし、要点に戻りましょう。 TSA（テストカバレッジの演劇的な品質）のスタイルでのテストは、先に進む前に完全に自分の信用を失っていると判断する必要があります。 非常に重要なアプリケーションはほとんどないため、すべてをテストする必要があります。
テストを通じて開発の開発に最も貢献した人、ケント・ベックの賢明な言葉で ：
テストではなく動作するコードに対して支払いを受けるため、私の哲学は、できるだけ少ないテストで正しいレベルの信頼を達成することです（私の信頼レベルは業界標準よりも高いと思いますが、私の自我）。 通常、特定のタイプの間違いを犯さない場合（たとえば、無効な引数をコンストラクタに渡すなど）、これをテストしていません。