Webアプリケーション開発におけるTDDの必要性
開発チームのメンバーは2人だけで、中規模のWebアプリケーション（Laravel）の作業を開始しました。
私の質問は、特にTDDのテストについてです本当にTDDを厳密にフォローし始めますか、それともテストフレームワークなしで開発を開始しますか後でテストのために何人かの開発者を雇いますか？
しかし、テストパターンに従わなかった場合、テスター（しばらくしてから来ます）が既存のコードベースをどのように処理するかについて説明します。
greenfield プロジェクトを開始する場合は、最初から自動テストを開始することをお勧めします。チームがTDDの経験が少ない場合、TDDをすべて実行することは困難な場合があります。最小 コードカバレッジ ターゲットを設定して（たとえば65％）、コードがテスト可能であることを確認します。
テストを自動化したいのはなぜですか？
- 要件の変化に応じてコードを安全にリファクタリングできる、または コードをクリーンで読みやすい状態に保つ
- 手動で繰り返しテストすることなく、自信を持って頻繁にリリースする
- 欠陥が発生したときにテストを追加できるため、テストの再発を防止
私は少なくとも書きます：
- 各クラスのユニットテストのカップル
- システムをブートストラップする統合テスト
- 各機能に対して単一のエンドツーエンドテストを記述します（UIがテスト可能であることを確認します。 PageObjects を使用して保守可能にします）
自動テスト用に設計されていないシステムにテストを追加することは、かなり困難で時間がかかるため、おそらく起こりません。それは苛立たしい状況になり、テスターはあなたを遅くする手動テストを好むでしょう。市場投入までの早いサイクルが必要な場合、または製品を最初からテストの自動化に集中させることができる場合。あなたがそうしなければ、あなたの製品はおそらく変化に抵抗するでしょう。
ティーチング開発者TDD：
- 私はコーディング道場のフォーマットが好きです： https://www.pluralsight.com/courses/the-coding-dojo
厳密なテスト駆動開発では、テストするコードを書き込む前に、コードの次のビットを書き込むためのテストが必要です。このように、APIを使用する試みは、APIの開発に良い影響を与えます。実装前にドキュメントを書くことも同様の影響を与える可能性があります。
テストが後で書かれている場合、それをTDDと呼ぶことはできません。
テスト自体は冗長である傾向があり、カプセル化を破る傾向があり、保守が困難な場合があるため、テスト自体は必ずしも長期的なテストに役立つとは限りません。副作用として自動化されたテストを伴う、それは設計手法の詳細です。
Niels van Reijmersdalが素晴らしい答えを出しました https://softwareengineering.stackexchange.com/a/343862/55065 それに2セントを加算させてください。
TDDであるかどうかにかかわらず、コードを記述した後で記述した場合でもテストを行うことをお勧めします。すぐに書いてください。
テスト部分とは別に、テストはプログラマの意図を伝えます。
100％のカバレッジは必要なく、厳密なTDDに従う必要はありませんが、2つのことを試みると、次のことが起こります。パーツ（これはTDDの自動的な利点です）。特に経験の浅い場合は、簡単とは簡単ではありません（ポイント1を参照）。