現在単体テストがないコード ベースに単体テストを組み込むための戦略はありますか?
7 に答える
Feathers による Legacy Code を効果的に使用するをお読みください。
Jimmy Bogard のSOC に関する優れたブログ シリーズがあります。
単体テストを行わずに既存のプロジェクトを改良する最善の方法は、バグを修正するときに行うことです。バグのあるロジックで失敗するテストと、バグを再現する手順を記述します。次に、テストに合格するまでコードをリファクタリングします。これで、バグが修正され、サイクルの後半に導入されることはないと確信できるようになり、プロジェクトに単体テストを導入し始めました。
テストに関する別の素晴らしい記事を次に示します。特に、それからのやや関連性のある引用:
これはひどい考えです。プロジェクトのテスト スイートを構築するのに 1 週間を費やすことに決めてください。まず第一に、イライラしてテストで燃え尽きてしまう可能性があります。第二に、おそらく最初は悪いテストを書くことになるでしょう。そのため、たくさんのテストを書いたとしても、どれだけ遅いか、壊れやすいか、または読みにくいかを理解するために、戻ってそれらを書き直す必要があります。
バグを修正したり、新しい機能を追加したりするときは、一度に 1 つのテストを作成する方がよいと思います... 不足しているテスト ケースを作成しようとしないでください。単にカバレッジを改善するのではなく、各テストの最終目標を設定する必要があります。 .
なぜユニットテストを追加したいのですか?コードにバグがあると思いますか?何かしたいだけですか?新しい機能に着手しようとしていますか?
それがかなり長い間リリースされている古い製品である場合、私は他の製品に同意し、バグを見つけたとき、または新しい機能を追加したときにのみテストを追加します。
それがまだ開発中であり、リリースされていないか、最近リリースされたばかりの製品である場合は、コードを確認することから始めます。正しくないものを見た場合は、テストを追加します。私はおそらくいくつかのサンプルデータを作成するためにいくつかのテストを行うでしょう。サンプルデータを作成することはあなたのお金にかなりの価値を提供するようです、そしてそれはまた役に立つかもしれません。
テストするバグがない場合でも、テストを作成することには利点があると思います。新しい機能を追加したり、後でバグを修正したりするときに、テストで新しいバグが発生していないことを確認します。
古いperlコードに単体テストを追加しようとしている場合は、強くお勧めします
Perlテスト: IanLangworthによる開発者用ノートブックとクロマチック。
これには、レガシーで「テスト不可能な」コードをテストする上で非常に優れたトリックがあります。
デールは投票されます。はい、機能しているコードに単体テストを追加しても何のメリットもありません。X と Y の 2 つの未知のバグがあるとします。ある時点で、X は通常のフィールド使用によって明らかになります。それを修正し、単体テストを追加して、次に進みます。ここで、プログラムの存続期間全体にわたって Y が発見されることはないと仮定しましょう。Y は自分自身を明らかにしなかったので、あたかも存在しなかったかのようです。リソースを無駄にする必要はありません。これに数百または数千の休眠中のバグを掛けると、余分なメンテナンスを大幅に節約できます。
私たちがパニックに陥り、単体テストとパフォーマンステストの間で混乱している可能性はありますか?アプリケーションは少数のユーザーで正常に動作しますが、負荷が高いとエラーがスローされ始めますか?もしそうなら、ユニットテストは答えではありません。ユニットテスト!=負荷テスト。
ユニットテストが実際に答えである場合は、コードをクリーンアップするのに役立つため、ユニットテストを後付けすることをお勧めします。たくさんリファクタリングする準備をしてください。TDDを使用して記述されたコードは、TDDを使用せずに記述されたコードとは大きく異なって見えることがわかります。私の場合、多くのケースを処理するメソッドHandleDisposition()がありました。TDDを使用してコードを記述した場合、この種のメソッドは存在しなかったでしょう。単体テストを改良するときに、その関数をリファクタリングし、XDisposition()、YDisposition()、ZDisposition()などのメソッドを追加しました。これらのメソッドは、単体テストを作成するのがはるかに簡単です。