3

これは単体テストのかなりマイナーな側面ですが、テスト実行中にテスト アサーションが失敗した場合に表示するように定義できる (多くの場合オプションの) 失敗メッセージに興味があります。 そのようなメッセージをいつ使用し、どのような情報をメッセージに含めるかについて推奨される方法はありますか?

たとえば、すべてのアサーションに失敗メッセージを定義する必要はないと思います。つまり、テストの期待される結果がどうなるかが明確な場合です。しかし、1 つのアクションを実行した後でオブジェクトのいくつかの側面をテストしたい場合があります。つまり、1 つのテスト メソッドにいくつかのアサーションがリストされている可能性があります。特定の時点でテスト メソッドが失敗した理由を簡単に確認できるように、そのシナリオの各アサーションに説明的な失敗メッセージを含める必要がありますか?

4

2 に答える 2

1

比較は、何が問題だったのかを判断するのに非常に役立ちます。JUnit の失敗メッセージは標準形式です。

と思ってthisいたのですが、取れthisました。

デフマークを表示していただけるとさらに良いです。

于 2012-06-29T13:56:45.973 に答える
1

かなり限られた数のケースで、カスタムの失敗メッセージが役立つことがわかりました。特に、オブジェクトのいくつかのプロパティをアサートする場合、期待値/実際の値では何が (そしてなぜ) 失敗したかについての最良の情報が得られない場合があります。次のようなテストを検討してください。

[Test]
public void CreateOrder_CreatesValidOrderForProvidedCustomer()
{
    // Assume we arranged test here

    var order = orderFactory.Create(customer);

    Assert.That(order.Type, Is.EqualTo("Immediate Dispatch"));
    Assert.That(order.Details, Is.EqualTo("Very Important Package"));
    Assert.That(order.CustomerNote, Is.EqualTo("Send fast or I tell mom"));
}

上記のアサートのいずれかが失敗した場合、次のようなメッセージが表示されます。

想定: 「非常に重要なパッケージ」 実際: 「迅速に発送」 .

単体テスト (正確には使用するデータ) を見ずに、どのプロパティが原因であるかを判断するのは困難です。ここでは、プロパティ名を失敗メッセージとして追加するだけで役立ちます。

しかし！

これは、複数のアサートされたプロパティをコンテンツごとに区別するのが難しいという極端なケースでした。通常、このような問題に直面することはありません ( 1語の長い期待メッセージを提供することで解決したことに注意してください)。長くて説明的な期待メッセージを使用する必要があると感じた場合、それはテストが過度に複雑であることを示している可能性があります。いくつかのテストに分割するか、テスト済みのクラスを再設計することを検討することもできます。

その上で、 FluentAssertionsのようなプロジェクトを検討することをお勧めします。彼らはそれを正しく理解しました：

理由を明確に説明せずに失敗する単体テストほど厄介なものはありません。

そして、非常にきれいな構文ときちんとしたエラー報告で問題を解決しました:

"1234567890".Should().Be("0987654321");

次のように報告されます。

文字列は
"0987654321" であると予想されますが、
"1234567890" は "123" (インデックス 0) 付近で異なります。

于 2012-06-29T14:13:29.477 に答える