Assert.That vs Assert.True

Question

What to prefer:

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

or

Assert.True(obj.Foo)

For me, both asserts are equivalent, so which one should be prefered?

Limoli

obj.Foo.Should().BeTrue(); fluentassertions.codeplex.com (it doesn't matter what you use, as long it's readable and delivers to reader what you tried to achieve) – Lenwood

twitter.com/jamesiry/status/74127537562857472 – Ectophyte

Assert has no "That" method, where does That come from? – Antoine

@Antoine NUnit – Leopoldeen

Not found archive.codeplex.com/?p=fluentassertions – Pozzy

Answer 1

In this particular case, there is no difference: you will see the output of roughly the same level of detail (i.e. it tells you that something that was expected to evaluate to true has evaluated to false). Same goes for

Assert.IsTrue(obj.Foo);

and

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

Your team should pick one style of assertions, and stick with it throughout all your tests. If your team prefers the Assert.That style, then you should use Assert.That(obj.Foo, Is.True).

Contrived

FWIW, our company goes with Assert.That so that your tests can read more like sentences. You would probably read both of these assertions as "Assert that obj.Foo is true", which is literally exactly how the second assertion is written. – Checkrow

Answer 2

Assert.That is called the constraint-based model. It's flexible because the method takes a parameter of IConstraint type. This means you can structure your code with a more generic hierarchy or calling structure, passing in any old IConstraint. It means you can build your own custom constraints

That's a design issue. As everyone is saying, no matter what you still need to provide decent error message feedback.

Spun

Good short explanation what is constraint-based assertion model. – Godhood

Useful response. Note, however the link appears to be mis-directed, the page for Nunit 3 is github.com/nunit/docs/wiki/Custom-Constraints – Bananas

Answer 3

So ok, you executed your test suite on CI server and unfortunately, one of them failed. You open the logs and see next message

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

Now how on earth would you get what happened wrong with this tests, if all the information you see, is that somewhere in AutoLoginTests bool was expected true, but received false? Now you need to go to the source file of your tests cases and see, what assertion failed. You see

Assert.True(obj.Foo)

Amazingly.. it's still hard to tell what's wrong, only if you developed this module 1 hour ago. You still need to go deeper into tests sources and probably production sources or even debug your code, so that you can at last figure out, that you misspelled a variable inside function call or used wrong predicate to filter registered users. Thus you blocked immediate feedback from tests, which is very valuable.

My point is that it's dosn't matter how fluent your assertions are (which are also relevant), but what information you expose in case of failing tests and how fast can you get the underlying reason of failure, even if you worked a long time ago with this functionaluty

Lenwood

You are completely right. This only was the question regarding the style. There should be a proper output if an assertion fail to easily findout the error. – Limoli

Answer 4

This is a bit nit-picky but IMHO I think that in this case Assert.That is unnecessarily verbose and can therefore be regarded as obfuscation. In other words, Assert.True is a little cleaner, more straightforward and easier to read and therefore comprehend.

To get a little more nit-picky I would suggest using the Assert.IsTrue API instead of Assert.True since, again IMHO, IsTrue "reads" better.

Bibeau

I tend to disagree, if you read the statements from left to right you literally get "Assert that object Foo is true" which leans more to the human language. (which is the purpose of Hamcrest). I also suggest to stick with Hamcrest or the default assertions, not mixing them. – Logging