views:

224

answers:

5

In a test that contains some asserts, for example:

Assert.AreEqual(1,1);
Assert.AreEqual(2,1);
Assert.AreEqual(2,2);

is it possible to let the test keep running after it fails at some point? In the example, first condition is true, second fails and the test stops. I'd like to evaluate also the following condition.

+5  A: 

No. Typically in this situation you would put all the code above the asserts into a setup method, then write each assert into its own test case.

Carl Manaster
Or use [TestCase].
Anna Lear
@Anna [TestCase] is useful when you have a numeric procedure, but if your setup is something more complex it quickly becomes a bit of a spagetti situation
Ed Woodcock
I agree with all of you with one assert per test; btw in this particular situation Anna's suggestion to use [TestCase] or catching AssertionException as suggested below do the trick.
m.bagattini
+2  A: 

Nope. You shouldn't really have more than one assert per test anyway, that reduces the seperation and makes it more difficult to find out which one failed.

If you have a lot of code that needs executing before the Assert, seperate it out into a [SetUp] function, or make it a seperate procedure.

Ed Woodcock
@EdW - one assertion per test is rather pedantic. I prefer to think of it as "assert one thing" per test. It may take multiple assertions to assert that "one thing", like does the thing I created have all the right properties. I'd prefer this over having one test per property because what you're really testing is "did the object get created properly?"
tvanfosson
@tvanfosson I'm just going with the general consensus here: it's easy enough to use [SetUp] to set up the relevant object, then do an Assert on it from multiple tests: it makes your tests easier to read, and if you use a CI thing (TeamCity, CruiseControl.Net, etc.) that handles unit tests for you it's much easier to see exactly what failed.
Ed Woodcock
@tvanfosson - IMHO, it would be okay to not write separate test case for each assert. But after the complexity builds, the test case will become brittle. That's when you want to refactor your test case to individual test cases for each assert.
Gutzofter
A: 

Asserts thrown an NUnit.Framework.AssertionException if they fail. You could catch that exception on the second assert, evaluate the third assert, then re-throw the exception.

Not something I'd recommend, though, for the reasons pointed-out by Ed Woodcock and Carl Manaster.

Andy Johnson
That's one of those things that's useful to know, but also very bad to know, because you might actually do it :)
Ed Woodcock
@Ed I agree, but the OP might have a good reason for doing this
Andy Johnson
@Andy other than laziness I can't think of one, apart from testing state-dependant data, which shouldn't really be done like that anyway.
Ed Woodcock
A: 

You could restructure your test to wrap the assertions in try/catch block and keep track of them for later validation. I don't recommend this, however. You really should be using separate tests for each condition if you want them to be tested independently.

  bool[] assertionSuccesses = new bool[] { false, false, false };

  try
  {
       Assert.AreEqual( 1, 1 );
       assertionSuccesses[0] = true;
  }
  catch (AssertionException) {}
  ...

  if (assertionSuccesses.Any( s => !s ))
  {
       Assert.Fail("one of the assertions failed");
  }
tvanfosson
A: 

You can cheat a little and not actually fail at a given point, but rather mark for failure, then fail at the very end, something like the following:

var sbError = new StringBuilder();
if (!SomeCondition()) {
  sbError.AppendLine("SomeCondition failed");
}
if (!SomeOtherCondition()) {
  sbError.AppendLine("SomeOtherCondition failed");
}
Assert.AreEqual(0, sbError.Length, sbError.ToString());

I wouldn't recommend this, but if you need to do it once or twice, it shouldn't be that bad.

Joe Enos