[解決済み] TDDと単体テストの比較 [終了しました］

質問

私の会社は、コードのユニットテストにかなり新しいです。 私はしばらくの間、TDD とユニットテストについて読み、その価値を確信しています。 私は、TDD が学習する努力と、プログラミングの方法に関する考え方を変える価値があることをチームに納得させようと試みましたが、それは苦労しています。 そこで、私の質問にたどり着きました。

TDDコミュニティには、テストを書いてからコードを書くことを非常に信奉している人がたくさんいますが（私も彼らと一緒です）、TDDで苦労しているチームにとって、妥協はまだ付加的な利益をもたらすのでしょうか？

私はおそらく、コードが書かれた後、チームにユニットテストを書かせることに成功することができ（おそらくコードをチェックするための要件として）、私の仮定は、それらのユニットテストを書くことにまだ価値があることです。

苦労しているチームをTDDに引き込む最良の方法は何でしょうか？ そして、それがコードが書かれた後であっても、ユニットテストを書く価値はまだあるのでしょうか？

EDIT

私がこの記事から得たのは、コーディングプロセスのどこかでユニットテストを始めることが重要だということです。 このコンセプトを理解しているチームのメンバーは、まず TDD とテストに向けて動き始めましょう。 皆さんの意見に感謝します。

フォローアップ

私たちは最近新しい小さなプロジェクトを開始し、チームのごく一部がTDDを使用し、残りはコードの後にユニットテストを書きました。 プロジェクトのコーディング部分を終了した後、コードの後にユニット テストを書いていた人たちは、TDD のコーダーがすでに終了し、より強固なコードを持っているのを見て驚きました。 懐疑的な人たちを味方につけるには、いい方法でした。 まだまだ成長痛は続きますが、意地の張り合いは終わったようです。 アドバイスをくれたみなさん、ありがとうございました。

どのように解決するのか？

もしチームがTDDの実装に手こずっているけれども、以前はUnit Testsを作成していなかったとしたら...コードが書かれた後にUnit Testsを作成することから始めてください。コードの後で書かれたユニット テストでさえ、ユニット テストがまったくないよりはましです!

いったん彼らがユニットテスト（とそれに付随するものすべて）に熟達したら、まずテストを作成し、次にコードを作成するように仕向けることができます。