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