単体テストのROIの明確な証拠はありますか？
ユニットテストは私には素晴らしいように聞こえますが、重要な価値がある他の人を納得させることができない限り、実際にそれを学ぶことに時間を費やす必要があるかどうかはわかりません。私は、他のプログラマー、そしてより重要なことに、管理のBean-Counterに、テストフレームワークの学習、テストの作成、テストの更新などに費やされるすべての追加の時間は、それ自体で採算が取れることを説得する必要があります。
どんな証拠がありますか？誰かが実際に同じソフトウェアを2つの別々のチームで開発しました。1つは単体テストを使用し、もう1つは使用せず、結果を比較しましたか？疑わしい。私はそれを「インターネットで調べて、みんながそれについて話しているので、それが正しいことであるに違いない」と正当化することになっているのでしょうか？
単体テストが努力に値することを素人に納得させる確かな証拠はどこにありますか？
はい。これは、NCSTのBoby GeorgeとLaurie Williamsによる研究への link であり、Nagppanらによる another による研究へのリンクです。まだまだあると思います。ウィリアムズ博士 publications テストについてそれらを見つけるための良い出発点を提供するかもしれません。
[編集]上記の2つの論文はTDDを具体的に参照しており、TDDを採用した後の初期開発時間の15〜35％の増加を示していますが、リリース前の欠陥は40〜90％減少しています。フルテキストバージョンを入手できない場合は、 Google Scholar を使用して、公開されているバージョンを見つけることができるかどうかを確認することをお勧めします。
「私は、他のプログラマー、さらに重要なことには、管理のBean-counterに、テストフレームワークの学習、テストの作成、更新の維持などに費やされるすべての余分な時間は、それ自体、そして一部は採算が取れるということを話さなければなりません。 」
どうして？
静かにそして離散的にそれをしないのはなぜですか。一度にすべてを行う必要はありません。あなたは小さな小さな断片でこれを行うことができます。
フレームワークの学習にはほとんど時間がかかりません。
1つのテストを1つだけ書くのに必要な時間はほとんどありません。
単体テストがなければ、あなたが持っているすべてはあなたのソフトウェアへのある程度の自信です。単体テストが1つあれば、自信はありますが、少なくとも1つのテストに合格したことを証明できます。
それだけです。あなたがそれをしていることを誰も知る必要はありません。早くやれよ。
私はこれに別のアプローチをとります：
コードが正しいことをどのように保証していますか？それとも、チームの誰かがfunc1（）を変更しても、仮定Xを破らないことですか？ユニットテストがあなたを「正直」に保つことがなければ、あなたが多くの確信を持っているとは思えません。
テストを更新し続けるという概念は興味深いものです。多くの場合、テスト自体を変更する必要はありません。本番コードと比較して3倍のテストコードがあり、テストコードはほとんど変更されていません非常に。しかし、それが夜によく眠れるようにし、システムを壊すことなくY機能を実装できると確信していることをお客様に伝えることができるのです。
おそらく学界には証拠があるかもしれませんが、私がこのようなテストに誰もがお金を払うような商業の世界で働いたことはありません。しかし、それは私にとってはうまく機能し、テストフレームワークに慣れるのに少しの時間しかかからず、テストを書くことで私は本当に私の要件と設計について考えるよりもはるかに多くのことを考えたと言えるでしょう。テストを作成しなかったチームで作業するときに、これを行いました。
ここで、それ自体が利益をもたらします。1）コードに自信があり、2）他の方法よりも早く問題を発見します。 QA担当者に「境界線チェックをしていなかったxyz（）関数をチェックしていませんでしたか？Heは、そのバグを見つけることができませんyoは1か月前に見つかりました。それは彼にとっても、あなたにとっても、会社にとっても、顧客にとっても良いことです。
明らかにこれは逸話ですが、私には不思議に働いています。スプレッドシートを提供できるかどうかわかりませんが、私の顧客は満足しています。それが最終目標です。
私たちは、単体テストなしで安っぽいソフトウェアを書くことが可能であるという確固たる証拠を示しました。単体テストを使った安っぽいソフトウェアの証拠さえあると思います。しかし、これは重要ではありません。
単体テストまたはテスト駆動開発（TDD）は、設計手法であり、テスト手法ではありません。テスト駆動で記述されたコードは、そうでないコードとは完全に異なって見えます。
これはあなたの質問ではありませんが、間違って尋ねられる可能性がある質問を答えて（そして他のレポートで挑戦されるかもしれない証拠をもたらす）、それが本当に簡単な方法かどうか疑問に思います。あなたがあなたの事件のための確固たる証拠を見つけたとしても-他の誰かが反対の証拠を見つけるかもしれません。
技術担当者がどのように作業するかを決定するのは、豆売りの仕事ですか？彼らはあなたがより高価なものを必要としないと信じているので、彼らはすべての場合で最も安いツールを提供していますか？
この議論は、信頼（アジャイルチームの基本的な価値の1つ）に基づいて勝ち取るか、または勝者の役割の力に基づいて負けます。 TDD支持者がロールパワーに基づいて勝利したとしても、私はそれを失われたと見なします。
厳密な単体テストよりもTDDについての詳細は、ここにリンクがあります テスト駆動開発による品質改善の実現：4つの産業チームの結果と経験 論文、Nagppan、E。Michael Maximilien、Thirumalesha Bhat、およびローリー・ウィリアムス。 Microsoftが発行した論文 Empirical Software Engineering and Measurement （ESM）グループであり、すでにここで言及されています。
チームが発見したのは、TDDチームが非TDDチームよりも（欠陥密度の観点から）60％から90％パーセント優れたコードを生成したことです。 ただしTDDチームは、プロジェクトを完了するのに15％から35％長くかかりました。
単体テストに対する証拠にも興味がある場合は、よく研究され、考え抜かれた記事を次に示します。
これは、彼の会社を内部から変えた男のすばらしい面白い読み物です。 TDDに限定されません。 http://jamesshore.com/Change-Diary/ 彼は「豆のカウンター」を長い間説得せず、代わりに「ゲリラ戦術」を行ったことに注意してください。
これらの回答にさらに情報を追加するために、学術的および業界の背景に対する生産性と品質の影響を理解するのに役立つ2つのメタ分析リソースがあります。
ゲストエディターの紹介：TDD-恐怖のないプログラミングの芸術[ リンク ]
すべての研究者は、TDDがより良いタスクフォーカスとテストカバレッジを促進することに同意しているようです。テストの数が増えるだけでソフトウェアの品質が向上するわけではありませんが、テスト設計へのプログラマーの関心の高まりは励みになります。テストを潜在的な行動の非常に大きな集団をサンプリングするものと見なす場合、より多くのテストはより完全なサンプルを意味します。各テストが他の誰も見つけることができない重要な問題を見つけることができる限り、テストは特に安価に実行できる場合に役立ちます。
表1.テスト駆動開発の選択された実証的研究の要約：業界の参加者*
表2. TDDの選択された実証的研究の要約：学術的参加者*
テスト駆動開発が外部の品質と生産性に及ぼす影響：メタ分析[ link ]
概要：
このペーパーでは、外部コードの品質と生産性に対するテスト駆動開発（TDD）の影響を調査する27件の研究の体系的なメタ分析を提供します。
結果は、一般に、TDDが品質に与える影響はわずかですが、生産性への影響はほとんどまたはまったくないことを示しています。ただし、サブグループ分析では、品質の向上と生産性の低下の両方が、学術研究と比較して産業研究ではるかに大きいことがわかりました。 TDDとコントロールグループのプロセスの間のテスト作業の違いが大きい研究では、生産性の大幅な低下が見られました。テストの努力の違いが大きい場合、質の大幅な改善が学術研究でも見つかりました。ただし、データが不足しているため、産業研究に関して結論を出すことはできませんでした。
最後に、開発者の経験とモデレーター変数としてのタスクサイズの影響が調査され、統計的に有意な正の相関がタスクサイズと品質改善の大きさの間に見られました。
単体/統合テストで見つかったバグを修正すると、実際のシステムでバグを修正した場合よりも何倍もコストが安くなることを証明する統計があります（実際のプロジェクトの監視に基づいています）。
編集：たとえば、指摘されているように、本「 Code Complete 」はそのような研究について報告しています（段落20.3、「Relative品質技術の有効性」）。しかし、それを証明するコンサルティング分野の民間研究もあります。
さて、ユニットテストを使用する必要があるいくつかの大企業がありますが、小規模な企業である場合、なぜ大企業を模倣するのでしょうか。
私にとって、何年も前に単体テストを開始したとき（今日は主に behavior モデルを使用しています）、1つのアプリケーションですべてのパスを制御できなかったためです。
私は最初のプログラミングとREPLに慣れていたので、ユニットテスト（関数ごとに1つのテスト）を取得すると、REPL=非常に多くのコンパイルが行われました。これにより、作成したコードのすべての行に楽しさが戻ってきました。私は神を感じました。私はそれが好きでした。より優れたコードをより速く書き始めたことを伝えるレポートは必要ありませんでした。上司は私たちがクレイジーなことをしているので、突然締め切りに間に合わなかったことに気づくレポートが必要です。これが原因で、上司は「プレーン」なバグの数が（多く）からほぼゼロになっていることに気づくためのレポートを必要としませんでした。非生産的なコードを書くという奇妙なこと。
別のポスターがすでに書いたように、TDDを使用してテスト（検証）することはありません。仕様（ユニット、オブジェクト、モジュール、関数、クラス、サーバー、クラスター）の動作の動作をキャプチャするために記述します。
多くの企業では、ソフトウェア開発の別のモデルへの切り替えに関する多くの失敗と成功事例があります。
新しいものを書くときはいつでもそれを使い始めました。私が英語に翻訳するのが少し難しい古いことわざがありますが、
気づかないほどシンプルなものから始めましょう。マラソンのトレーニングをするときは、まず9メートル歩いて1メートル走って、繰り返します。
私にはこれのためのデータセットが1セットあります-単体テストで私を売った経験から。
何ヶ月も前に、私は大規模なVB6プロジェクトに取り組んでいる新卒であり、大量のストアドプロシージャコードを記述する機会がありました。私が書いていたサブシステムのうち、コードベース全体の約1/4を占めていました（50Kあたり約13,000 LOC）。
ストアドプロシージャの単体テストのセットを作成しましたが、Rational Robotのようなツールがないと、VB6 UIコードの単体テストを実際に実行することはできません。少なくとも当時はそうではありませんでした。
ピースのQAからの統計は、サブシステム全体で約40または50の欠陥が発生したことであり、そのうちのtwoが発生したストアドプロシージャから。これはコードの6,500行ごとに1つの欠陥であるのに対し、ピース全体で1,000〜1,200あたり1つの欠陥です。また、VB6コードの約2/3がエラー処理とログ記録の定型コードであり、すべての手順で同じであることも覚えておいてください。
手振りが多すぎない場合は、不良率の少なくとも1桁の改善を単体テストに帰することができます。