私たちのプロジェクトは現在メンテナンス中です。このプロジェクトの単体テストは一度もありません。アプリケーション全体の単体テストを書くのではなく、デルタの単体テストを書くことを計画していました。好ましいアプローチは何でしょうか。メンテナンス段階で単体テストを追加することは本当に価値があるのでしょうか??? まだ .net 1.1 を使用しており、将来的に .net 4.0 にアップグレードする可能性があります。
誰かがこれをビジネスに販売するためにROIを行ったのではないかと思っていました??
3 に答える
3
推奨されるアプローチは、差分を作成する前に既存のコードをすべて単体テストでカバーすることですが、そのための予算がない場合があります。変更の単体テストは、何もないよりは確実に優れています。
適切な統合/検証/受け入れテストがすでにある場合は、それで十分です。
于 2010-05-27T21:06:46.430 に答える
2
理想的には、将来のデルタだけでなく、プロジェクト全体をカバーする単体テストを用意する必要があります。これは、主要なインフラストラクチャのアップグレードを計画している場合に特に重要です。これは、基本的にプロジェクト全体が「デルタ」であることを意味するためです。
これに力を注ぐ価値があるかどうかは、このプロジェクトを今後どれだけサポートしたいかによって異なります。
于 2010-05-27T21:23:28.833 に答える
0
それはすべて、コードがチャーンされる頻度と理由によって異なります。ただし、いずれにせよ、単体テストと包括的な単体テスト スイートは、長期的な投資に似ています。
変更の大部分がフィールド/顧客の問題によるものである場合、メンテナンス フェーズの (レガシ) コードの UnitTest の ROI は、問題を修正する時間を短縮し、デルタで導入 (または公開) されたバグの数を減らすことから得られるはずです。問題の根本原因を特定する時間を短縮します。
コード チャーンが小さな機能 (改善および/または顧客の要求) によって引き起こされている場合、ROI は短い納期 (コードの品質の向上、信頼性の向上、TDD の有効化など) からもたらされるはずです。
単体テストは一般に、コード ベースに対する開発者の信頼を高め、変更に対するある種の安全ネットを提供する必要があります。
于 2010-05-28T13:00:45.120 に答える