Understanding unit test constraints and NUnit syntax helpers

Question

Me and a colleague are starting a new project and attempting to take full advantage of TDD. We're still figuring out all the concepts around unit testing and are thus far basing them primarily on other examples.

My colleague recently brought into question the point of the NUnit syntax helpers and I'm struggling to explain their benefit (since I don't really understand it myself other than my gut says they're good!). Here is an example assertion:

Assert.That(product.IsValid(), Is.False);

To me this makes complete sense, we're saying we expect the value of product.IsValid() to be false. My colleague on the other hand would prefer us to simply write:

Assert.That(!product.IsValid());

He says to him this makes more sense and he can read it easier.

So far the only thing we can agree on is that you are likely to get more helpful output when the test is failing from the former, but I think there must be a better explanation. I've looked up some information on the syntax helpers (http://nunit.com/blogs/?p=44) and they make sense, but I don't fully understand the concept of constraints other than they 'feel' right.

I wonder if someone could explain why we use the concept of constraints, and why they improve the unit test examples above?

Thanks.

Answer 1

I think it's mostly to do with the pure English reading of the statement.

The first reads

Assert that product is valid is false

The second reads

Assert that not product is valid

I personally find the first easier to process. I think it's all down to preference really. Some of the extension methods out there are interesting though that let you do you assertions like this:

product.IsValid().IsFalse();

Answer 2

I can see your version being better than your colleagues. However, I'd still be at least as comfortable with:

Assert.IsFalse(product.IsValid());

If you can convince me that the Assert.That syntax has an objective benefit over the above, I'd be very interested :) It may well just force of habit, but I can very easily read the "What kind of assertion are we making? Now what are we asserting it about?" style.

Answer 3

It's all sugar. Internally they're converted to constraints.

From Pragmatic Unit Testing, pg 37:

"NUnit 2.4 introduced a new style of assertions that are a little less procedural and allow for a more object oriented underlying implementation. ... For instance:

Assert.That(actual, Is.EqualTo(expected));

Converts to:

Assert.That(actual, new EqualConstraint(expected));"

Using constraints also allows you to inherit from Constraint and create your own custom constraint(s) while keeping a consistent syntax.

Answer 4

I don't like Assert.That, specifically the fact that its most common scenario (comparing two objects' equality) is measurably worse than the 'classic' Assert.AreEqual() syntax.

On the other hand, I super love the MSpec NUnit extensions. I recommend you check them out (or look at the SpecUnit extensions, or NBehave extensions, or N*Behave*Spec*Unit extensions, I think they're all the same).