Enter!バッチを起動しようと勢いよくキーを叩いたら、それはシフトキーだった。Railsの生みの親Davidが最近のTDDについて苦言を呈しています。賛否両論あると思いますが、大変参考になるポストなので、勝手に和訳してみました。(誤訳等ありましたら、ツッコミ願います)(原文はコチラ)TSAロックのようにテストする最初、開発者はテスト駆動開発に驚きを感じ、ストレスや不安の少ない素晴らしい世界の入り口に立ったかのような気になるんだ。確かにそれは素晴らしい経験で祝福すべきことだ。テストによる恩恵を自分のものにすることは、悟りの第一段階にすぎない。何をテストすべきでないかを知ることはさらに難しいことなんだ。初日から何をテストすべきでないかなんて気にしなくていい。2日目から始めればいい。人間とは習性をもつ生き物で、『テストのしすぎ』という悪い習性を早くから身につけてしまうと、後から振り落とすことは難しい。早めに振り落とすべきなんだ。本番環境に移行するときにたった一つでもバグを発見できたら・・・それは価値の無いことなのかい?」・・・無いわけないだろ。ここで論じたいのは、どうやって我々はTSAロックを手に入れたかということ、どうやって彼らは何十億もの金玉いじりと爪切りの没収に時間を費やしたかということだ。テストはタダじゃないコードの全ての行にはコストがかかっている。書く時間、更新する時間、そして読む時間と理解する時間。従って、テストによってもたらされる恩恵は、テストを作成するコストよりも大きくならなければならない。ない場合、それは過剰なテストということだ。バグを防ぐためのコストとは何かと。(あー、分かった分かった。ないなら、忘れるこった)過剰なテストを大声で叫ぶことの問題は、キャッチャーなフレーズに煮詰めることが難しいことだ。テスト駆動開発をしかるべき舞台の中心に推し進めるのを手助けする、テスト・ファースト、レッド−グリーン、その他のセクシーな言葉のように簡潔ではないんだ。よい有用なテストとは、ニュアンス、経験、そして決めの細かい発見的方法を伴うものだから。7つの「してはいけない」テストしかし、十分に理解した参加者と行う夕食2時間の会話のニュアンスは、ブログに投稿するほど多くない。そこで、典型的なRailsアプリのテストについて、次の意見リストで論争を発火させてみようと思う。カバレッジ100%を目指すなプロダクトコードとテストコードの比率が1:2を超えたら・・臭う。全体の作業時間の3分の1以上をテストに費やしているのなら、それはたぶん間違っている。半分以上なら、明らかに間違いだ。scopesをテストするな。別々の要素を統合することによる課題をテストするために統合テストをするんだ。(単体テストでできるテストを統合テストでするな)Cucumberを使うな。ノンプログラマー達がテストを書き上げる魔法の国にでも住んでない限りは。(もし本当に住んでるなら、妖精を瓶詰めにして送ってほしい)コントローラ、モデル、ビューに対して、常にテスト・ファーストを自制するな。(僕の場合は、20%がテスト・ファースト、80%がテスト・アフターだ。)我々は何百もの書籍をもって、どうやってテスト駆動開発を始めるかを知るが、野獣を飼い慣らす1、2つの方法に集中することを願うよ。大事なことは最初にしておこう。TSAスタイルのテスト(現場の品質カバー)は我々が前進できる以前に、信用できないものだと総括しなければならない。全てをテストするに値するほどクリティカルなレベルのアプリケーションは殆ど無いだろ。テスト駆動開発の第一人者として名高いケント・ベックの言葉の中に、素敵な言葉ある。私はコードが機能するかに注意を払い、テストには払わない。私の哲学は、信頼できるレベルに達する程度で可能な限りテストを少なくするということだ。(信頼できるレベルというのは業界標準と比べて高いのではないかと思う。ヘンな訳になっちゃってスイマセンですが・・要はコスト意識を持て、ということなんだと思います。ほとんどの場合において『充分にに良く』テストすればそれでいいじゃん、という感じでしょう。enoughってやつですね。検索:プロフィールitmammothIT界のマンモスを目指しているフリーエンジニアです。麻婆豆腐/Ruby/Kotlin/麻婆春雨/Python好きです。最近カリフラワーも好きになりました。