翻訳者から。 この記事では、David Heinmeyer Hanssonが、 TDDの強制的な使用、さらにはコードを書く前にテストを書くことによる害の可能性についてのホットなトピックを取り上げました。 TDDが生きているかどうかのトピックに関する5回の会議のライトモチーフとして機能したのは、この記事で、David、Kent Beck、Martin FowlerがTDDの長所と短所、適用範囲と制限について話し合いました。 話された英語を十分に理解していない人のために、 SergeyTは彼のG +に短いサマリを公開しています。
「先読みテスト」アプローチの原理主義は、禁欲に限定された性教育です。それは、自己嫌悪と恥に満ちた非現実的で効果のない道徳化キャンペーンです。
最初はすべてが異なっていました。 私がTDDを初めて知ったのは、より良いプログラミングの世界への親切な招待のようなものでした。 これまでテストがまったくなかった場所でテストを継続して練習するために、意識を変えてください。 十分にテストされたコードベースの静けさ、およびコードに変更を加えることに自信を持っているという至福を感じました。
「先のテスト」アプローチは素晴らしいサポートホイールであり、より深いレベルでのテストについて考える方法を教えてくれましたが、すぐにそれを放棄しました。
数年後、「先のテスト」のレトリックはより大きくて意地悪になりました。 もっと意味がある。 そして、時々、原理主義のじょうごに吸い込まれ、真の聖句に従わなかったのが気分が悪くなりました。 そのような瞬間、私は数週間「先のテスト」を練習しようとしましたが、私のプロジェクトが悪化したときに再び終了しました。
それは振り子の効果でした。教義の手紙に固執することができたときの誇り、そうでないときの絶望の崩壊。 それはネクタイの後に飲み始めるようなものです。 沈黙し、社会に現れない。 人前で、せいぜい、コードを書く前にテストを書くとは限らないと言って、最悪の場合、私はこのアプローチを本当に真実としてサポートし続けました。 申し訳ありません。
業界を破壊するためのラムとして、「先読みテスト」アプローチを使用する必要があったのかもしれません。「申し訳ありませんが、自動化された回帰テストはありません」。 たぶんそれは、日常のプログラミングスタイルの文字通りの説明であるはずのないたとえ話でした。 しかし、それがどのように考えられても、すぐにすべてがうまくいきませんでした。 そして今、それは不信者を倒すためにハンマーのように使用されます。リトマス試験のように、他のすべての人をプログラミングに不向きで不適切であると宣言します。
十分。 十分。 私の名前はDavidで、コードを書く前にテストを書きません。 私はこのことについて謝罪することを拒否します。 TDDにより、自動化されたリグレッションテストがすべての栄光で見られるようになったことに感謝しますが、このアプローチの教義から長い間離れています。
このアプローチが設計の整合性にどのように影響するかを批判的に検討することをお勧めします。 あなたがこれが絶対に良くないという可能性を正直に考慮に入れたいなら、赤い丸薬を選んでください。 あなたはあなたが後に見るものが好きではないかもしれません。
それで、私たちはどこに行くのでしょうか？
ステップ1：問題があることを認識する必要があります。 ちょうどやったと思います。 2番目のステップは、テストスペクトルをモジュールからシステムにシフトすることです。 TDDに対する現在の熱狂的なアプローチは、コードの設計（「先のテスト」アプローチの最初の理論的根拠）を制御できると考えられているため、ユニットテストに焦点を当てています。
私はこれが真実だとは思わない。 「先読み」アプローチでは、データベースへのアクセスなどの「遅い」操作を避ける必要があるため、中間オブジェクトとラウンドアバウトの構造が非常に複雑になります。 または、読み取り/書き込みファイル。 または、ブラウザでテストを実行して、システム全体を確認します。 その結果、私たちは巨大な建築物の創造に来ました。 オフィス施設、チームなどの密集した雑木林。
すべての依存関係が濡れ、数千のテストを数秒で完了するという、従来の意味でのユニットテストを作成することはめったにありません。 Railsアプリケーションをテストする良い方法ではありませんでした。 Active Recordsモデルを直接テストし、実際のデータベースへのアクセスを提供します。 テストはコントローラーレベルで機能しますが、さらに進んで、これらのテストをCapybaraのさらに高いレベルのテストに置き換えます。
これが私たちの進むべき方向だと思います。 ユニットテストへの注意が減りました。これは、デザインプラクティスとして「先のテスト」アプローチを使用しなくなったためです。また、低速なシステムテストへの注意が高まりました。 （ちなみに、並列化とクラウドインフラストラクチャを使用しているため、遅くする必要はありません）。
Railsはこの移行に役立ちます。 今日、私たちは完全なシステムテストを奨励するために何もしていません。 スタックにはデフォルトのツールはありません。 しかし、この欠陥を修正する予定です。 しかし、これが起こるまで待たないでください。 今日カピバラを試してみてください、明日はどこにいるのかがよくわかります。
しかし、最初に深呼吸してください。 私たちは今、屠殺のために神聖な牛を率いています。 これは非常に痛いです。 TDD手法は非常に成功しているため、現在では多数のプログラマーのIDに組み込まれています。 TDDは彼らがすることだけでなく、彼らが誰であるかということです。 TDDの制御から抜け出すためにプログラム解除を行っていますが、しばらく時間がかかります。
私たちができる最悪のことは、単にテストの別の宗教に突入することです。 ゴールデンカーフは「システムテストのみ」だと簡単に想像できます。これはしないでください。
はい、私にとって「先のテスト」アプローチは死んでいます。 しかし、彼の墓で踊るのではなく、TDDの多大な貢献を認めたいと思います。 TDDは私たちの歴史の重要なマイルストーンをマークしますが、それは先へ進む時です。
テストを長持ちさせます。