CODEWITHSUNDEEP
unit-testingnunit
David Hoerster
David Hoerster

Reputation: 28711

Is there a reason not to use AssertionHelper with NUnit?

I've been using NUnit for a while now, and I have been deriving my test classes from AssertionHelper. By doing that, my tests use a syntax like:

Expect(myValue, Is.EqualTo(3), "value wasn't equal to 3");

instead of:

Assert.That(myValue, Is.EqualTo(3), "value wasn't equal to 3");

Almost every example with NUnit that I see uses Assert.That() syntax, but it seems that Expect() makes more sense (at least to me) as I am expecting a certain behavior from my code.

Is there any downside to using AssertionHelper with NUnit, or is it really come down to just a matter of taste/style?

Thanks in advance!

Upvotes: 7

Views: 784

Answers (4)

daf
daf

Reputation: 1329

Rob Prouse is correct that the NUnit team is deprecating AssertionHelper. I had been using it for about 8 months when I found it was obsoleted in an update and I offered to maintain it. The discussion around that was going really slowly and I was a little impatient, so I wrote NUnit.StaticExpect which is on Nuget and offers a drop-in replacement for AssertionHelper, with a "using static" import in your code. I switched a production project over to it and it's working well.

I also started around that time on a different path: NExpect which offers a syntax more reminiscent of Chai but with extensibility more similar to Jasmine. NExpect is in a pretty usable state -- I've been using it in my own projects for a while now. There's a demo project which you can use to observe the evolution of assertions through:

  1. Assert.{specific method} (eg Assert.AreEqual)
  2. Assert.That({value or lambda}, {current-tense constraint})
  3. AssertionHelper usage
  4. NUnit.StaticExpect usage
  5. NExpect usage

As well as giving an example of the extensibility of NExpect. Hope this helps.

Upvotes: 0

Rob Prouse
Rob Prouse

Reputation: 22657

The main issue with AssertionHelper is that very few people use it, so new NUnit features and constraints tend not to get added to it. Because it is neglected and not widely used, the NUnit team is considering removing it or making it a separate package.

The team is looking for feedback from the community on whether or not to remove it, so feel free to comment on the issue.

Upvotes: 1

onedaywhen
onedaywhen

Reputation: 57093

Because of the way I name my variables, my tests often end with the line:

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

which IMO reads better (more fluent) than

Expect(actual, Is.EqualTo(expected));

Upvotes: 0

sll
sll

Reputation: 62564

Both doing the same and both allows you specifying a custom constraint which implements IConstraint interface. From my point of view Assert() a little bit lightweight since does not obligate you inheriting all test fixtures from a special class.

Upvotes: 5

Related Questions