One way to test this would be to write a custom constraint, LeapYearConstraint. You
could then use it with the Matches syntax element to write your test as

Assert.That( array, Is.All.Matches( new LeapYearConstraint() );

But creating a new constraint for this adhoc problem seems like a bit of overkill.
Instead, assuming you are working with C# version 3, try this:

Assert.That( array, Is.All.Matches( (x) => x%4 == 0 && x%100 != 0 || x%400 == 0 );

If it fails, it will give a generic message: “Expected: matching lambda expression” since NUnit is actually
built with .NET 2.0, but for a quick test it may be just the tool you need.

Reason 1: Data-Driven Tests

Users of mbUnit and xUnit.net have enjoyed the flexibility that data-driven (aka parameteried) tests provide for some time. NUnit implements this paradigm in its own way, with it’s own set of attributes. Test methods may have arguments and the data for them may be supplied in a number of ways: inline, from a separate method or class or randomly. This feature gives you a succinct way to express a set of examples to be used in running individual test cases.

Reason 2: Theories

As used in NUnit, a Theory is a generalized statement of how a program should operate, like “For any positive number, the square root is defined as the positive or negative number, which, when multiplied by itself, gives the original number.” Traditional, example-based, testing allows you to select one or more sets of values to use in testing such a program. A Theory, on the other hand, allows you to express the generalization itself, writing a test that will pass for whatever values are passed to it, provided they meet the stated constraints. David Saff has written a number of papers about the use of Theories in testing and has implemented this construct as a part of JUnit. Now you can use the same construct in any .NET language.

Reason 3: Inline Expected Exception Tests

Testing that an expected exception is thrown correctly has always been an issue in NUnit. The ExpectedExceptionAttribute has been available since early releases but has a number of problems. It tests that the exception was thrown somewhere in the test, without specifying the exact place in the code, and it is subject to the syntactic limitations that apply to use of an attribute. With the introduction of the Assert.Throws assertion method and the even more powerful constraint expressions Throws.Exception, Throws.InstanceOf and Throws.TypeOf, exception testing logic can now be moved right into the test along with any other necessary assertions.

Reason 4: Generic Support

NUnit 2.5 provides separate framework assemblies for .NET 1.x and 2.0+. Using .NET 2.0 or higher, a number Up to 2.4, NUnit avoided any use of Generics, in order to maintain backward compatibility. In 2.5, the framework assembly used under .NET 2.0 provides a number of generic Asserts and Constraint expressions for convenience. More significantly, your test methods and classes may now be generic, and NUnit will specialize them using the types you provide.

Reason 5: Lambda Support

If you write your tests using C# 3.0, you may use Lambda expressions in a number of places where NUnit expects a delegate. This is particularly useful in providing a custom definition of equality without explicitly defining an IComparer<T> and can even be used to apply an arbitrary predicate to the members of a collection.

Reason 6: Out-of-Process Execution and Runtime Selection

NUnit 2.4 ran all tests within the same process, using one or more AppDomains for isolation. This works fine for many purposes, but has some limitations. NUnit 2.5 extends this concept to running tests under one or more separate processes. Aside from the isolation it provides, this allows running the tests under a different version of the .NET runtime from the one NUnit is currently using.

Reason 7: PNUnit

PNUnit stands for “parallel NUnit” and is an extension developed by Pablo Santos Luaces and his team at Codice Software and contributed to NUnit. It’s a new way to test applications composed of distributed, communicating components. Tests of each component run in parallel and use memory barriers to synchronize their operation. Currently, pNUnit uses a special executable to launch its tests. In the future, you will be able to run pNUnit tests from the standard NUnit console or gui runner.

Reason 8: Source Code Display

The new stack trace display in the Errors and Failures tab of the Gui is able to display the source code at the location where a problem occured, provided the source is available and the program was compiled with debug information. Currently, syntax coloring for C# is provided and other languages are treated as simple text, but additional syntax definitions will be available in the future.

Reason 9: Timeout and Delayed Constraints

These are two separate features, but they are related. Besides, I’m working hard to keep this down to only ten points! It’s now possible to set a timeout, which will pre-emptively fail a test to fail if it is exceeded. This may be done on a method, fixture, assembly or as a global default. On the other hand, if you need to wait for an action to take place after a delay, you can use the After syntax to delay the application of the constraint. NUnit will subdivide a long delay and apply your test repeatedly until the constraint succeeds or the specified amount of time is up!

Reason 10: Threading Attributes

In past releases, if any test needed to run in the STA, the entire test run had to use the STA. With 2.5, any method, fixture or assembly may be given an attribute that causes it to run on a separate thread in the STA. Other attributes allow requiring an MTA or simply running on a separate thread for isolation. This can eliminate a lot of boilerplate code now required to create a separate thread, launch it and capture the results for NUnit.

This is my own list, of course. Yours may vary. Download the release, try it out and let me know what your own favorites are.

There are two reasons for generating this code. The first relates to the syntactic constructs. While it’s relatively straight forward to create a custom constraint and various people have done so, such constraints must be used by invoking their constructors rather than by use of a simple key word. So, for example, if you have written an OddNumberConstraint that tests whether a number is odd and displays an appropriate failure message, you are still not able to write Assert.That(num, Is.Odd) without directly modifying NUnit.

It turns out, based on experience of several people who have tried, that the syntactic modification has a lot of places where you can go wrong. You have to modify at least three additional files, even after you have written the constraint. Using NUnit’s code generation facility, you would simply add a line like this to NUnit’s SyntaxElements.txt:

Gen3: Is.Odd=>new OddConstraint()

Then, after running NUnit’s code generation tool, the files Is.cs, ConstraintFactory.cs and ConstraintExpression.cs would be updated. After rebuilding NUnit - or just the framework - the statement Assert.That(num, Is.Odd) would compile and work correctly. If you wanted a classic assert, you could add the line

Gen: Assert.IsOdd(int num)=>Assert.That(num, Is.Odd)

and Assert.IsOdd would become available for your use, including overloads with an error message and optional arguments.

So, one good reason for generating code is to make it easier to extend NUnit. But an even more important reason is reliability. Take the Assert class as an example. Some of the methods have as many as 24 overloads. In the past, we have seen hidden bugs that affected only one infrequently used overload. By generating the code, we can ensure that the same logic is used in each overload. This doesn’t prevent errors, but it does make it likely that the error will be caught, since it will generally impact many of the overloads in the same way. What’s more, the layout of the SyntaxElements file puts things that need to be updated together right next to one another, so it’s much harder to forget a step.

The NUnit code generation program, GenSyntax.exe, is distributed with the NUnit source, in the tools directory.

Some of the new features are similar to approaches taken in mbUnit, about which Ben has written in past blogs. As it happens, those posts were often the best - and sometimes only - source of information I could find on how those features ought to work. So thanks for the cross-pollination you provide, Ben!

In this blog, I’ll show how this might be done:
1. Without any support from the testing framework.
2. With a basic ExpectedException attribute
3. With a handler, as provided by NUnit 2.4
4. With a Throws.Exception constraint, as provided by NUnit 2.5

What I hope to show is that Throws.Exception gives us the level of control we have when we do it all ourselves, while providing a level of ease of use that is comparable to - if not better than - what we get from ExpectedExceptionAttribute.

First, we need an example. Let’s say that we have a method that is supposed to throw an argumentexception if the passed in argument is in an invalid state for the desired operation. Of course, this would be a pretty poor design choice in most situations, but lets just assume this is the way it has to be and that we simply need to test it.

Here’s the test I might write using a try/catch block.

[Test]
public void TestThatProperExceptionIsThrown()
{
  try
  {
    MethodUnderTest(anInvalidObject);
    Assert.Fail("Expected an exception, but none was thrown");
  }
  catch(ArgumentException ex)
  {
    Assert.AreEqual( ex.ParamName, "myParam" );
    Assert.AreEqual( ex.Message, "My message" );
  }
  catch(Exception ex)
  {
    Assert.Fail( "Expected an ArgumentException but got a "
      + ex.GetType().FullName );
  }
}

This is somewhat tedious to write, so programmers were happy to get an ExpectedExceptionAttribute to use instead. With that support, you could write

[Test,ExpectedException(typeof(ArgumentException))]
public void TestThatProperExceptionIsThrown()
{
  MethodUnderTest(anInvalidObject);
}

Or even

[Test,ExpectedException(typeof(ArgumentException), ExpectedMessage="My message")]
public void TestThatProperExceptionIsThrown()
{
  MethodUnderTest(anInvalidObject);
}

But what about ParamName? NUnit 2.4 introduced the notion of an exception handler, allowing you to write:

[Test,ExpectedException(typeof(ArgumentException), ExpectedMessage="My message",Handler="MyHandler)]
public void TestThatProperExceptionIsThrown()
{
  MethodUnderTest(anInvalidObject);
}

public void MyHandler(Exception ex)
{
  Assert.AreEqual("myParam", ((ArgumentException)ex).ParamName);
}

This gives us the functionality, but is somewhat verbose. A more serious problem is that there may be additional code in the test method, before or after the method call. This approach does not guarantee us that the exception came from a particular method.

NUnit 2.5 takes care of this with a new Assert and a corresponding Constraint. Assert.Throws was borrowed from the xunit.net framework, and is best for simpler cases:

Assert.Throws<ArgumentException>( { delegate MethodUnderTest(anInvalidObject) } );

The corresponding constraint syntax, using Throws.Exception is unique to NUnit and allows us to meet our original requrements in a single statement:

Assert.That( delegate { MethodUnderTest(anInvalidObject },
  Throws.Exception<ArgumentException&gt.(),
  Has.Property("ParamName").EqualTo("myParam") &
  Has.Property("Message").EqualTo("My message") );

For new applications, I recommend you set aside ExpectedException and use either Assert.Throws or Throws.Exception. That way, what you are testing is clearly stated right in the code, for everyone to see.

[TestFixture(typeof(ArrayList))]
[TestFixture(typeof(List<int>))]
public class IList_Tests<TList> where TList : IList, new()
{
  private IList list;

  [SetUp]
  public void CreateList()
  {
    this.list = new TList();
  }

  [Test]
  public void CanAddToList()
  {
    list.Add(1); list.Add(2); list.Add(3);
    Assert.AreEqual(3, list.Count);
  }
}

NUnit will create an tree branch containing two fixtures, one that uses ArrayList and another using List. Combined with features like TestCase, this can be quite powerful.

This feature is available in the current source code and will be included in the Alpha-3 release.

As with all of NUnit’s Visual Studio builds, the VS2008 build is provided for the convenience of folks who want to build their own copy of NUnit. Our “official” releases are all built with NAnt and anyone who wants to work that way may, of course, do so themselves. Last time I checked, you could also build NUnit with one of the Express editions, so you have lots of options.

Currently, the VS2008 build uses .NET 2.0. I’m not envisioning a separate build for .NET 3.5 until NUnit 3.0. Of course, that could change if we come up with a good reason to change it.

With the NUnit 2.5 alpha releases, NUnit continues to support that extension - and even bundles a copy of it. But NUnit 2.5 also introduces its own set of attributes for data-based testing, beginning with the TestCaseAttribute, which I will describe here.

Here’s a simple use of this new attribute…

[TestCase(12, 3, 4)]
[TestCase(12, 2, 6)]
[TestCase(12, 4, 3)]
[TestCase(12, 0, 0, ExpectedException = typeof(System.DivideByZeroException),
      TestName = “DivisionByZeroThrowsExceptionType”)]
[TestCase(12, 0, 0, ExpectedExceptionName = “System.DivideByZeroException”,
      TestName = “DivisionByZeroThrowsNamedException”)]
public void IntegerDivisionWithResultPassedToTest(int n, int d, int q)
{
      Assert.AreEqual(q, n / d);
}

This creates five different test cases, displayed and reported separately. The two last tests show alternate ways to specify an expected exceptionl. Note the use of the TestName property, to specify a meaningful name for each of these cases.

Since this test consists of a single Assert.AreEqual statement, we can simplify it further by modifying the test method to return a result and indicate the expected result with the result property…

[TestCase(12, 3, Result = 4)]
[TestCase(12, 2, Result = 6)]
[TestCase(12, 4, Result = 3)]
[TestCase(12, 0, ExpectedException = typeof(System.DivideByZeroException),
      TestName = “DivisionByZeroThrowsExceptionType”)]
[TestCase(12, 0, ExpectedExceptionName = “System.DivideByZeroException”,
      TestName = “DivisionByZeroThrowsException”)]
public int IntegerDivisionWithResultCheckedByNUnit(int n, int d)
{
      return n / d;
}

For more information on this feature, see the NUnit documentation.

As compared to 2.4, NUnit 2.5 has quite a lot:

• Data-driven tests using [TestCase] and [DataSource]
• Additional asserts and constraints, including inline exception tests.
• Parallel and distributed testing using pNUnit.
• Bundled addins, now including RowTest and CSUnitAddin.

For more info, see the release notes.

In addition, watch the NUnit mailing lists or this blog for info about other extensions as they are released for NUnit 2.5.