c# - Assert.That vs Assert.True

Question

何を好むか:

Assert.That(obj.Foo, Is.EqualTo(true))

また

Assert.True(obj.Foo)

私にとって、両方のアサーションは同等なので、どちらを優先する必要がありますか?

Answer 1

この特定のケースでは、違いはありません。ほぼ同じ詳細レベルの出力が表示されます (つまり、評価されると予想されていたものが に評価されたことがわかりますtrue) false。同じことが言えます

Assert.IsTrue(obj.Foo);

と

Assert.That(obj.Foo, Is.True);

チームは 1 つのスタイルのアサーションを選択し、すべてのテストでそれを使い続ける必要があります。Assert.Thatチームがこのスタイルを好む場合は、を使用する必要がありますAssert.That(obj.Foo, Is.True)。

Answer 2

さて、CI サーバーでテスト スイートを実行しましたが、残念ながらそのうちの 1 つが失敗しました。ログを開くと、次のメッセージが表示されます

BusinessLogicTests.LoginTests.UserAutoLoginTests failed: expected true but was false

AutoLoginTests bool のどこかで true が期待されていたのに false を受け取ったというすべての情報が表示された場合、一体どうやってこのテストで何が間違っていたのかを知ることができますか? 次に、テスト ケースのソース ファイルに移動して、どのアサーションが失敗したかを確認する必要があります。分かりますか

Assert.True(obj.Foo)

驚くべきことに..このモジュールを 1 時間前に開発した場合にのみ、何が問題なのかを判断するのはまだ困難です。関数呼び出し内の変数のスペルを間違えたか、登録ユーザーをフィルター処理するために間違った述語を使用したかを最終的に把握できるように、テスト ソースやおそらく運用ソースをさらに深く掘り下げるか、コードをデバッグする必要があります。したがって、テストからの即時のフィードバックをブロックしました。これは非常に価値があります。

私の要点は、アサーションがどれほど流暢であるか (これも関連性があります) は問題ではなく、テストに失敗した場合に公開する情報と、たとえ長時間働いたとしても、失敗の根本的な理由をどれだけ早く取得できるかということです。この機能の前に

Answer 3

これは少しうるさいですが、私見では、この場合Assert.Thatは不必要に冗長であるため、難読化と見なすことができると思います。言い換えれば、Assert.True少しクリーンで、より直接的で読みやすく、したがって理解しやすいということです。

もう少し細かいところまでこだわるには、代わりに API を使用することをお勧めしAssert.IsTrueます。Assert.TrueIsTrue