NUnit Assertions and Syntax

Test Code is typically placed under separate project in its own assembly.

• Set up all conditions needed for testing (create any required objects, allocate any needed resources, etc.)
• Call the method to be tested
• Verify that the tested method functioned as expected
• Clean up after itself.
  

NUnit can be used in 3 ways:
From Command Line
From NUnit GUI
As a Plug-In to Visual Studio

NUnit Asserts:

AreEqual
Assert.AreEqual(Expected, Actual, [, string message])
Assert.AreEqual(Expected, Actual, tolerance, [, string message])

IsNull
Assert.IsNull(object [, string message]
Assert.IsNotNull(object [, string message])

AreSame
Assert.AreSame(expected, actual [, string message])

IsTrue
Assert.IsTrue(bool condition [, string message])
Assert.isFalse (bool condition [, string message])

Fail
Assert.Fail ([string message])

[TestFixture] + Public + default constructor - A class level attribute for making nunit understand its a test class. A [TestFixture] class should always be declared as public so that Test Runners can find it and it must a public no parameter constructor (Default Constructor)

[Test] - Method - Test Method inside a test class where you write the actual unit tests.

[Suite] (Test Suite) static method inside test class - A group of [TestFixture] classes helps to run a bunch of test. Though this is a good way of grouping things, may not be greatly useful in the real time as we might want to group [Test] methods across different [TestFixture] classes and run the bunch once.

Categories - A category is just a name you define. You can use NUnit categories to help sort out short test that you can run constantly versus long-running tests that you'd rather only run during the nightly build.- Category can be applied to an individual [Test] method or an entire [Test Fixture]

Ex: [Category ("Short")], [Category ("Long")] - Here "Short" & "Long" are the names we defined for categories.

In Nunit GUI "Short" and "Long" will be listed under available categories. We can just select one category and choose to run.

To run from command line /include=string;string - Here string stands for category But this isn't quite enough: it urns out that some categories of test should be run when no categories are selected, while others should run only when explicitly selected...

To support this, you can specify the Explicit property to the [Category] attribute:

[Category ("SpecialEquipmentNeeded", Explicit=true)] - This automatically excludes the category from default run (when we don't specifically select any categories)

When running multiple tests in a sequence, sometimes we might need to reset some parts of testing environment between the tests. Nunit lets you specify two methods to set up and then tear down the test’s environment using attributes:

[SetUp] - The method marked with [SetUp] attribute are executed before each one of the test methods is executed.

[TearDown] - The method marked with [TearDown] is called after each test method is executed.

[TestFixtureSetUp] – This method is executed at the class level before [Test] methods in the class are executed

[TestFixtureTearDown] – This method is executed after the execution of all the [Test] methods in the [TestFixture] class

Both Per-Class and Per-Method attributes can be used in same class

Custom Asserts: The standard asserts that NUnit provides are usually sufficient for most testing. But sometimes we need to build our custom asserts like when our application has got a special data type, or when we have a piece of code that needs to be repeated across multiple tests. We can write our own assert style methods for this purpose.

NUnit & Exceptions:
There are two types of exceptions that could occur

1. Expected exceptions resulting from a test – Something like a method throws an exception when no values are passed and we are trying to test the same with a test method.
2. UnExpected exceptions from something that’s gone wrong in method exection.

Expected Exceptions can be handled with .. you got it right, [ExpectedException] attribute.
Ex: [Test, ExpectedException(typeof(ArgumentException))]
This indicates that this test method is now expected to throw an exception. If it doesn’t it will fail. Note that once the expected exception fires, any remaining code in the test method will be skipped.

Un Expected Exceptions are taken care by NUnit itself. It catches any thrown exception and reports it an error along with entire stack trace.

Temporarily Ignoring Tests
Sometimes we first write tests and then work on the implementing the code required to pass these tests. In such cases we don’t want the testing framework to run these tests just yet. NUnit provides [Ignore] attribute for that.

[Test, Ignore(“Not read to test yet”)]

Nunit reports this method is skipped and shows it in yellow so that we don’t forget about it later.

DRY principle - Don’t Repeat Yourself – It s a fundamental technique that demands that every piece of knowledge in a system must have a single unambiguous, and authoritative representation.