状況: 数百万行のコード、100 人を超える開発者、頻繁な欠陥。私たちは欠陥の繰り返しを避けたいと考えており、コード設計を改善したいと考えています (そうしない人がいるでしょうか?)。
テスト駆動開発 (最初の単体テスト、次にコード) は理想的に聞こえます。関数ごとにテスト ケースを作成します。
しかし、これほど多くのコードが書かれている中で、TDD をどのように実装できるのでしょうか? どこから始めますか? 低レベル関数から?
それとも、TDD を開始するには遅すぎますか?
4911 次
2 に答える
24
レガシー コードから始める場合、実際には TDD ではありませんが、コーディングはすべて TDD にすることができます。新しい問題に取り組むときは、そのためのテストを書きます。それができない場合は、レガシー クラスをテストするのが難しすぎるために、それらのテストを書き始め、ビットを切り取り、ビットをテストでカバーします。
欠陥の繰り返しを避けるために: 与えられた欠陥の例に対して、それを実証するテストを書きます。これは、ユーザー アクティビティをシミュレートするだけの比較的広範なテストになる可能性があります。まだ単体テストではありません。テストが失敗することを確認します。調査を行います。テストが失敗する理由を見つけます。さて、これは重要です。バグを修正する前に、バグを実証する単体テストを作成してください。バグを修正すると、リグレッションから保護する 2 つのテスト (少なくとも 1 つは高速) が得られます。
于 2010-07-08T13:56:17.450 に答える
2
Carl が 1 つの本を提案したので、別の本を提案します。Roy Osherove のArt of Unit Testingには、「レガシー コードの操作」に関する章全体があります。その章はまだ読んでいませんが、最初の 5 章は素晴らしく、楽しみにしています。
于 2010-07-08T16:32:39.500 に答える