既知の欠陥の単体テストは必要ですか？

コードに既知の欠陥が含まれていますが、修正する必要がありますが、まだ修正されておらず、現在のリリースでは修正されず、近い将来修正されない可能性がある場合、テストスイート？単体テストを追加すると、（明らかに）失敗します。失敗したテストに慣れるのは悪い考えのようです。一方、既知の欠陥であり、既知の失敗事例がある場合、ある時点で修正されるべきであり、テストはすでに利用可能であるため、テストスイートに入れないようにするのは奇妙に思えます。

答えはイエスです。それらを作成し、実行する必要があります。

テストフレームワークには「既知の失敗したテスト」のカテゴリが必要であり、これらのテストはそのカテゴリに該当するものとしてマークする必要があります。その方法はフレームワークに依存します。

不思議なことに、突然失敗するテストの失敗は、予想外に失敗するテストの成功と同じくらい興味深いことがあります。

私はあなたが現在の振る舞いとユニットテストを持っていて、コメントに正しいテストと正しい振る舞いを追加すべきだと思います。例：

@Test
public void test() {
  // this is wrong, it should be fixed some time
  Assert.assertEquals(2, new Calculator().plus(2,2));
  // this is the expected behaviour, replace the above test when the fix is available
  // Assert.assertEquals(4, new Calculator().plus(2, 2));
}

このように、修正が利用可能な場合、ビルドは失敗し、失敗したテストに気づきます。テストを見ると、動作を変更したことがわかり、テストを更新する必要があります。

編集：キャプテン・マンが言ったように、大規模なプロジェクトでは、これはすぐには修正されませんが、文書化のために、元の答えは何もないよりはましです。

それを行うより良い方法は、現在のテストを複製し、クローンに正しいことをアサートさせ@Ignore、メッセージでそれをさせることです。例えば

@Test
public void test() {
  Assert.assertEquals(2, new Calculator().plus(2,2));
}

@Ignore("fix me, Calculator is giving the wrong result, see ticket BUG-12345 and delete #test() when fixed")
@Test
public void fixMe() {
  Assert.assertEquals(4, new Calculator().plus(2, 2));
}

これには、@Ignoredテストの回数を減らすためのチームの慣習があります。バグを反映するためにテストを導入または変更するのと同じ方法ですが、チームにとって重要な場合はビルドに失敗しないことを除き、OPはバグ修正が現在のリリースに含まれないと言っています。

テストツールに応じて、omitまたはpend関数を使用できます。

ルビーの例：

gem 'test-unit', '>= 2.1.1'
require 'test/unit'

MYVERSION = '0.9.0' #Version of the class you test 


class Test_omit < Test::Unit::TestCase
  def test_omit
    omit('The following assertion fails - it will be corrected in the next release')
    assert_equal(1,2)
  end

  def test_omit_if
    omit_if(MYVERSION < '1.0.0', "Test skipped for version #{MYVERSION}")
    assert_equal(1,2)
  end

end

omitコマンドは、テストをスキップし、omit_ifテストと結合し、それを-私はバージョン番号をテストし、唯一の私は、エラーが解決される期待のバージョンでテストを実行し、私の例では。

私の例の出力は次のとおりです。

Loaded suite test
Started
O
===============================================================================
The following assertion fails - it will be corrected in the next release [test_omit(Test_omit)]
test.rb:10:in `test_omit'
===============================================================================
O
===============================================================================
Test skipped for version 0.9.0 [test_omit_if(Test_omit)]
test.rb:15:in `test_omit_if'
===============================================================================


Finished in 0.0 seconds.

2 tests, 0 assertions, 0 failures, 0 errors, 0 pendings, 2 omissions, 0 notifications
0% passed

私の答え：はい、テストを実装します。ただし、テスターとエラーを混同しないでください。

バグがあなたの心に新鮮であり、ユニットテストを今書く時間があるなら、私は今それを書いて、既知の失敗としてフラグを立てて、ビルド自体が失敗しないようにします。バグトラッカーは、このバグに対して現在失敗しているユニットテストがあることを反映するように更新する必要があります。そのため、最終的に修正する担当者は、それを繰り返し書きません。これは、バグのあるコードは多くのリファクタリングを必要とせず、APIが大幅に変更されることを前提としています。その場合、テストの作成方法をよりよく理解するまで、ユニットテストを作成しない方が良いかもしれません。

答えは私見ではありません。バグの修正作業を開始するまでバグの単体テストを追加しないでください。バグを証明するテストを作成し、バグレポートに従ってテストが失敗した場合は、 s）テストに合格するために実際のコードを修正します。バグは解決され、その後カバーされます。

私の世界では、バグが修正されるまでQEが失敗する手動テストケースがあります。そして、開発者としての私たちは、手動で失敗したTCおよびバグトラッカーを介してそれを認識します。

失敗したUTを追加しない理由は簡単です。UTは、開発者として私が現在取り組んでいるものの直接的なフィードバックと検証のためのものです。そして、UTはCIシステムで使用され、そのモジュールの他のコード領域で意図せずに何かを壊さないようにします。既知のバグであるHOのためにUTが意図的に失敗することは、逆効果であり、単なる間違いです。

答えは本当にあると思う、それは依存する。それについて実用的である。今、それを書くことで何が得られますか？たぶんそれはあなたの心に新鮮ですか？

バグを修正するとき、バグを公開する単体テストを書くことによって存在することを証明することは完全に理にかなっています。その後、バグを修正すると、単体テストに合格するはずです。

失敗した単体テストを今書く時間はありますか？作成/修正が必要な追加の緊急機能またはバグはありますか。

バグが記録された有能なバグ追跡ソフトウェアを使用していると仮定すると、失敗した単体テストを今すぐ記述する必要はありません。

バグ修正なしで行われているリリースの前に失敗した単体テストを導入すると、おそらく混乱を招く可能性があります。

リストが時間の経過とともに大きくなりすぎたり、同じテストの無関係なエラーが「期待」として却下されたりするのは簡単すぎるため、テストスイートで既知のエラーが発生することは通常不安です。同じことが断続的な障害にも当てはまります-コードに潜んでいる何か悪いことがあるかもしれません。現在のコードのテストを作成することに投票します。修正したら修正する必要がありますが、コメントアウトするか、何らかの方法で無効にします。