TDDが開発の品質や速度を改善した方法のケーススタディを探しています[非公開]

私の会社では、なぜTDDを行うべきなのかを主張しようとしています。現在、ほとんどの開発者はプロジェクトを完了させるためにできる限りのことを行ってから、マネージャーの指標を満たすために事後に単体テストを追加します。TDDを実施し、利益を確認している評判の良い企業の例は大歓迎です。

IBMとMicrosoftの4つのプロジェクトの研究。掲載されましEmpericalソフトウェアエンジニアリングジャーナル。

実証研究はテスト駆動開発が品質を改善することを示す

Empirical Software Engineeringジャーナルレポートで最初に発表された論文：「TDDはさまざまな分野に適用できるようで、開発チームの生産性を大幅に低下させることなく、開発したソフトウェアの欠陥密度を大幅に削減できます。」この調査では、TDDを使用したMicrosoftとIBMの4つのプロジェクトを、TDDを使用していない同様のプロジェクトと比較しました...

このペーパーには、IBMでの1つのケーススタディとMicrosoftからの3つのケーススタディが含まれています。各ケーススタディでは、同じ開発言語とテクノロジを使用して同じ製品で作業している2つのチームを、同じ上位レベルマネージャーの下で比較し、テスト駆動開発（TDD）を使用しているチームは1つだけです。どのチームも、開発サイクル中に調査に参加することを知りませんでした。IBMのケーススタディは、デバイスドライバー開発を行うチームを追跡しました。Microsoftの事例は、Windows、MSN、およびVisual Studioで作業しているチームを追跡しました。

このペーパーでは、チームが分単位のワークフローとして使用するTDDプラクティスと、タスクレベルのワークフローについて説明します...

TDDに関する章が最近の本「ソフトウェアの作成：何が機能するのか、なぜそれを信じるのか」のケーススタディで説明しています。しかし、あなたが失望するかもしれません。私が正しく思い出せば、この研究はTDDの本当の利点を明らかにしなかったからです。とにかくケーススタディは面白かったし、この本は私が最近読んだ最高のソフトウェア本の一つだ。ペアプログラミング、コードレビューなどの多くのケーススタディが含まれています。

間違いなくこれをチェックしてください：TDD実証済み効果的！またはそれは？

... Phil Haackが、TDDの有効性を研究がサポートすると発表したとき、リンクされたレポートに実際に含まれているものを見ることに少し興味がありました。フィルは要約から引用します。

テストファーストの生徒は平均してより多くのテストを書いており、その結果、より多くのテストを書いた生徒は生産性が高い傾向があることがわかりました。また、採用した開発戦略に関係なく、プログラマーテストの数に応じて最小品質が直線的に向上することも確認しました。

フィルは明らかにレポートの残りの部分を読み、タイトルが示唆するように見える彼のお気に入りの作品を提供しています。しかし、最新かつ最高のソフトウェア開発プラクティスをサポートするものを見たときに心配することの1つは、現在の理論の確認を求め、カウンター指標を見落とすという、確認バイアスへの強い傾向です。

だから、好奇心が強いタイプであり、TDDは私がいつか自分を採用したいと思うかどうかを監視しているので、レポートに行きました...

...疑いもなく、最初にテストを行うと、機能ユニットごとにテストが増えます。問題は、これが価値があるかどうかです。この研究は、少なくとも品質があなたの意図した利益である場合、おそらくそうではないことを示しているように思われます。しかし、コードの行数が生産性に対応していないことに驚かないのと同じように、テストの数が品質に対応していないことはそれほど驚くことではありません。

著者は、TDDがそれほど効果的ではないことについて多くの良い点を持っています（死に誇示されているにもかかわらず、imo）

あなたとクライアントがソフトウェアの手動テストに費やした時間を調べます。それをTDDスタイルの自動テストにかかった推定時間と比較してください。ポケットの違い

私の経験では、TDDの自動化されたテストは、保険を提供し、膨大な量の手動テストを排除するため、ゴールドです。

Andres Fが指摘したように、これらの利点は単にTDDではなく自動テストから得ることができます-ただし、TDD は後付けや便利なものではなく自動テストを必要とします

最初にテストについて考えることを余儀なくされると、コードの記述を開始する前に、モジュール性、インターフェース設計などの品質関連の問題について考えることも余儀なくされます。

個人的には、TDDの最大の利点の1つは、最初にテストを記述することで、コードの作成中にコードが実際に実行する必要があることの仕様が、並べ替えるのではなく、心の中で新鮮に保たれることです-as-you-code。

あなたはそれを主張したい：あなたは次のプロジェクトのためにそれを行うことを提案し、それから学びます。それがあなたのためにうまくいくことが判明したなら、私はあなたがそれを使い続けることを望み、プロジェクトを行うのに時間がかかり、そして/またはコーディングの代わりにテストを書くのにすべての時間を費やすなら、あなたは確かにそれをダンプします失敗。

実世界のソリューションは（ほとんどのものと同様に）途中であり、テストが必要ですが、テストがプロジェクトよりも重要であることは望ましくないと思います。

（個人的にはTDDは流行であり、理論上は良いと思うが、実際には...あまり良くない。統合テストははるかに重要だと思うが、それは私が取り組んでいる一種の複雑なプロジェクトかもしれない）。

私はTDDを2年間使用しており、当時働いていた場所では、マネージャーを含めて使用することに消極的でしたが、すぐに正しいことをするようになりました。すぐに気付いた利点は

• 早い段階でバグを発見する。
• 実現することなく、より良いコードを書く。
• テストはすべて小さなチャンク（300〜400行の機能がありました）であるため、コードのメンテナンス性が向上しました。現在、最大30個、すべて独立してテストされています。

彼らは皆、「終わった」という一つのことに興味があるので、マネージャーは知りません。しかし、彼らはソフトウェアが実現せずに壊れ続けると文句を言います。優れたカバレッジと賢明なテストにより、誰かが機能を壊したときに本当に見ることができる量ではなく品質です。また、残念ながら、自分でいる場合は困難です。ソフトウェアの一部をテスト可能にするために、ベースクラスなどのコードを変更する必要がある可能性があるため、同じ問題がありました。

私はあなたに例を与えます私はリポジトリをモックしたかったのですが、インターフェースがなく、リポジトリをサービス層に注入する必要があり、したがってショップ全体にコンストラクタを追加/変更する必要がありましたが、これは大したことですが、最後に、システムの1つの領域をテストするだけで200以上のテストがあり、感銘を受けました。

私は通常、次のことを行います。

• ユニットテストは非常に短くします
• 1つだけアサートします。ロシアンルーレットはありません。
• 正負の例外シナリオをテストします

私が恐れているケーススタディについては、私が見たことがあるかどうかわかりません。プロジェクトを構築して、ケーススタディになる必要があります。

私はそれが役立つことを願っています