0

私は python unittest のユーザーですが、これはすべての言語にまたがっています。

シナリオ: 「functionBeingTested」の欠陥を発見しました。
欠陥は、有効な入力でコードがクラッシュする (例外をスローする) ことです。

テストケースを書くとき、私は非常に簡単にできます：

def testThis(self):
    self.assertEqual( functionBeingTested("valid input"), "expected output")

TDD の用語では、これは「失敗」すると予想されますが、代わりに例外が発生し、「エラー」が発生します。

 Ran 1 tests with 0 failures and 1 errors

あなたが望むと仮定するでしょう：

 Ran 1 tests with 1 failures and 0 errors

このPython 単体テストには解決策があります: Reporting Exception as Failure

ここでの同様の議論:例外がスローされない場合は単体テストに合格する

しかし、それは問題ではありません。

問題は「テスト スイートを維持するためのベスト プラクティス」です。

純粋なテスト駆動開発で「エラー テスト ケース」を作成することは哲学的に許容されますか?それとも、この単体テストを作成して例外をキャッチし、アサーション エラーを発生させて、代わりに「失敗」を示す必要がありますか? 'エラー'。

この質問に光を当てることができなかったいくつかの読書: http://www.computer.org/portal/web/swebok/html/ch5#Ref1.1.2
"IEEE Standard Glossary of Software Engineering Terminology" (google it)

そして、Python 2 と Python 3 の unittest ドキュメント間の編集を見てください: http://docs.python.org/2/library/unittest.html#organizing-test-code http://docs.python.org/3/library /unittest.html#organizing-test-code

Python 3 では、このフレーズが省略されたようです。

[error] は、問題がどこにあるかを特定するのに役立ちます。失敗は、誤った結果 (6 を予期していた場所) によって引き起こされます。

この質問の他のタイトルが検討されてい
ます。
または
「「失敗」と「エラー」の哲学的な違いは何ですか、
または
「TDDでは、すべての「失敗したテスト」は「失敗」をスローするか、「エラー」を許容するように書かれるべきですか」

「1つはアサーションエラーで、もう1つはそうではない」などの簡単な回答を得ずに、私がここで求めていることを正確に特定しようとしていますが、喜んで反対票を投じます。

4

1 に答える 1

1

例外をスローすることは、失敗を示す 1 つの方法です。これは、テストの前提条件の 1 つが満たされていないことを意味します。「この呼び出しは例外のスローに失敗しましたか」と尋ねることは、一般的に興味深いものではありません。そうでなければ、すべてのコードについて尋ねなければならない質問です。

「この公称有効な入力により、例外がスローされる」というバグが発見されたという事実は、テスト スイートにバグがあったことを示しています。入力の一部のクラスがカバーされていませんでした。例外がスローされる原因となる入力のクラスは、一般に、期待される出力がどうあるべきかについて、わずかに特殊化されたルールを必要とするため、カバーされていないバグの修正として、新しく発見されたバグのテストを表現することには、ほとんどの場合、記録的な価値があります。 .

はい、あなたが書いたテストは2つのことをテストします。しかし、それがテストすることの 1 つは、興味深いものではないため、明示的にテストするべきではありません。退屈なテストは悪いテストです。

于 2013-03-14T23:57:01.587 に答える