3

単体テストが記述されたソリューション ファイルに多数のプロジェクトがあり、それらを継続的インテグレーション サーバーで実行できるように設定したいと考えています。ただし、テストの多くは適切に作成されておらず、定期的に実行されていないため、多くのテストが失敗しています。

現時点では、すべてのテストを修正する時間はありませんが、既存のテストを実行することには価値があると信じています。失敗した単体テストに対処する最善の方法は何ですか?

私が現在行っていることは、失敗した各テストを Explicit としてマークし、TODO コメントを残すことです。

[Test, Explicit] //TODO: Rewrite this test because it fails

これを行うより良い方法はありますか？それとも、CIS によって実行されるテストに含める前に、すべてのテストを修正する必要がありますか?

4

6 に答える 6

8

自動ビルドが実行されているため (テスト失敗通知付き!)、これは 1 日 5 回 (ubuntu コミュニティから無料で) の時間のように思えます。

失敗している各テスト メソッドに、次の (疑似コード) を挿入します。

if  ( DateTime.now < new DateTime(2008, 12, 24, 11, 00, 00)) return;

このステートメントを 5 回挿入するごとに、日付が 1 営業日進みます。テストを修正する時間がある可能性が高い時間帯を設定します。

営業日が来たら、それを修正または削除します。

于 2008-12-22T08:01:31.783 に答える
6

さて、NUnit では、ignore 属性を使用してテストを無視するオプションがあります。

[Test, Ignore("Test needs rewrite")]

ただし、個人的には、このようなテストで行うことが 2 つあります。

  • テストが理解できない場合、またはテストが古い/現在の仕様と同期していない場合は、それらを削除してください
  • 修正が簡単な場合は、正しい仕様にリファクタリングします

あなたが書いたことから収集すると、これらの失敗したテストの多くは時代遅れであり、そもそも関連性がない可能性があると思われるので、それらを削除しても問題ないと思います.

とにかく誰も理解できないテストを続けても意味がありません。

更新: Oren Einiのブログ投稿があり、古い失敗したテストを有効にすることについて私がどのように感じているかを概説しています。

テスト自体に価値はない: 私の最も成功したプロジェクトにはテストがありませんでした

引用するには：

テストはツールであり、プロジェクトに適用する前に、その使用法を通常のメトリックに対して評価する必要があります。テストを使用しない理由はたくさんありますが、それらのほとんどは、「プロセスに摩擦を加える」ことに要約されます。

古い失敗したテストを改造してプロセスに摩擦が加わる場合、それらを更新する価値はまったくないかもしれません。

于 2008-12-22T07:37:07.027 に答える
3

テストを単に削除するという考えには同意しません。機能するように見えても機能しない場合、それは重要な情報です。テストがほとんど問題なく、失敗の原因となっている環境 (たとえば、現在別の場所にあるローカル ファイルの読み取り) がある場合、時間を見つけて修正すると、簡単に再び値を提供できます。でも：

  • テストが失敗した理由を説明するコメントを追加します。これが他の場所のバグによるものである場合は、バグ ID などが役立ちます。1 年後に戻ってくるのに十分な情報を提供してください。
  • テストのことを忘れないように、何らかのツール (おそらく非常に簡単な場合があります - grep!)​​ でレポートを生成します。
  • 可能であれば、無視されたテストを定期的に自動的に実行して、まだ失敗するかどうかを確認する方法を見つけてください。失敗していたテストが魔法のように機能し始めると、非常に重要な情報が得られます (もちろん、ソース履歴と併せて)。
于 2008-12-22T08:12:45.193 に答える
2

現時点では、すべてのテストを修正する時間がありません

ここに何か後ろ向きなものがあると思います...

テストに価値があると本当に考えているのであれば、それを修正しない時間がないことをお勧めします。現在、彼らは、ソフトウェアが本来の機能を実行していないか、テストが適用されなくなったものをチェックしていると言っています。いずれにせよ、プロセスがどこかで壊れていることを示しています。

そのため、特に時期を考えると、月末または年末の問題がない限り、テストまたはコードのいずれか、またはその両方をクリーンアップする時間を作ることになります。

真剣に、彼らの言うことを聞かなければ、テストを受ける意味はありませんか? また、継続的インテグレーションの機能が信頼できないのに、なぜわざわざ継続的インテグレーションを実行するのでしょうか?

于 2008-12-22T09:02:09.617 に答える
1

すべてのテストを実行する継続的インテグレーション サーバーを適切にセットアップしています。

しかし、無効化されたテストは何の役に立つのでしょうか? それらはコメントアウトされたコードのようなものです。デッドテスト。Jonが言ったように：それらを実行させるか、削除してください。あなたの言うようにうまく書かれていない場合は、新しいものを書いたほうがよいことがよくあります。

しかし、いつそれらを修正する時間がありますか? テストは、ソフトウェア開発者がさらに先に進むための唯一のセーフティ ネットです。時間がかかるか、後で支払う必要があります。しかし、おそらく新しいテストを書くのにかかる時間は短くなるでしょう...

于 2008-12-22T08:08:40.067 に答える
0

技術的負債が蓄積された他のコードをどうしますか?

TDD (最初にテスト) を実行する場合、単体テストは 2 つのことを行います。1 つは、カップリングが低く凝集度が高いオブジェクトの設計を支援することです。これらのテストは、もはやあなたのためにばかげたことをしていません。2 つ目は、動作を変更せずにコードをリファクタリングできるようにすることです。

失敗したテストが機会費用になっているようです。言い換えれば、プロジェクトに付加価値がなくなったということです。お金と時間がかかるだけです。それらをどうするか考えて過ごした時間を見てください。テストはもはや有効ではありません。

私見、私はテストを削除します。コードをリファクタリングすると、テストが動作を保護しないなど、コードはもはやカバーされていません。コードに変更されたコメントがあるようなものですが、コメントは更新されていません。

テストを削除する場合は、テストでカバーされていたと思われるコードを「レガシー」(Feather's Definition) として扱う必要があります。

于 2008-12-22T08:12:40.683 に答える