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