Reputation: 13325
Isn't it true that every assert statement can be translated to an Assert.IsTrue, since by definition, you are asserting whether something is true or false?
Why is it that test frameworks introduce options like AreEquals, IsNotNull, and especially IsFalse? I feel I spend too much time thinking about which Assert to use when I write unit tests.
Upvotes: 0
Views: 627
Reputation: 1611
You can write framework agnostic asserts using a library called Should. It also has a very nice fluent syntax which can be used if you like fluent interfaces. I had a blog post related to the same.
http://nileshgule.blogspot.com/2010/11/use-should-assertion-library-to-write.html
Upvotes: 0
Reputation: 19117
It is very simple - to make your test code more readable.
Which is more readable
Assert.IsTrue(quantity > 0)
or
Assert.That(quantity, Is.GreaterThan( 0 ))
Don't you think the second option is more readable?
Upvotes: 1
Reputation: 754515
Given enough extra code on your part, yes it's true that almost every Assent.XXX
can be turned into an Assert.IsTrue
call. However there are some which are very difficult to translate like Throws
Assert.Throws<ArgumentNullException>(() => x.TestMethod(null));
Translating that to an Assert.IsTrue
is possible but really not worth the effort. Much better to use the Throws
method.
Upvotes: 4
Reputation: 3739
Yes,
The AreEqual(obj1, obj2) basically does a Assert.IsTrue(obj1.Equals(obj2)). So, I would say this is true.
But perhaps they introduce those overloads for readability, per example make it obvious they want to compare two objects, or check if a value is equal to false.
Upvotes: 2
Reputation: 62027
You can use Assert.IsTrue
all the time if you prefer. The difference is Assert.AreEqual
and the like will give you a better error message when the assertion fails.
NUnit (and probably other frameworks) now supports syntax like this:
Assert.That(foo, Is.Equal.To(bar))
Upvotes: 4