Whatever Blows Your Hair Back

So you’ve dug in and started directly testing (using the extension methods I provided in Part I) your protected and private methods where, hopefuly, the vast majority of your business logic resides. In this post I want to show you how to invoke a method that is an overload on the same class. Using the GetMethod method on Type will puke if more than one method with the same exact name exists on the type you’re attempting to call. Here’s how to fix that problem:

	// Call the AddException method on the _importer object.
	// The 2nd parameter to 'Call' is the parameter list to pass to AddException
	// The 3rd parameter to 'Call' is the types of the parameters expected by the AddException method
	_importer.Call("AddException", new object[] { new Exception("blah") }, new [] { typeof(Exception) });

You can see that the parameter list is an object[] so the Type.GetMethod method has no way of differentiating between two methods with the same name solely by looking at the parameters passed in. You have to specifically tell it, “Hey, I want you to call the ‘AddException’ method that expects an ‘Exception’ parameter.

Some might say, why not just create a phat testing base class instead of creating these extension methods. You could do that. However, I personally feel that this is slightly cleaner and a bit more readable. There are times when a testing base class comes in quite handy and I pretty much always use one… for a completely different reason though.

Let’s take a traditional look at how to write a test where you expect an exception to be thrown.

[Test, ExpectedException(typeof(ApplicationException))]
public void Demonstrate_NUnitWayOfExpectingExceptions()
{
	// This 'throw' will cause the test to pass because this test is
	// decorated above with the 'ExpectedException attribute.
	throw new ApplicationException(exceptionMessage);
}

If you do it this way, there’s no (decent) way to look at the thrown exception or do anything beyond where the exception is thrown. That’s not exactly ‘ideal’ when more than one type of exception could be thrown or if you want to do multiple things in the same method after the exception is thrown. Now let’s look at a slightly better way to do just that.

If you downloaded the source code in Part I, you’ll find a class named TestingBase.

[Test]
public void Demonstrate_ExpectException()
{
	// ExpectException (on base class) is great when you expect an exception but
	// ... the ExpectedException attribute just doesn't give you enough flexibility
	string exMessage = ExpectException<ApplicationException>(() => { throw new ApplicationException(exceptionMessage); });
	Assert.IsNotNull(exMessage);
	Assert.AreEqual(exMessage, exceptionMessage);

	// We're also free to continue more testing and still be in the same 'state'
	// Here we can write several lines of code 'inline'... no problem.
	exMessage = ExpectException<FileNotFoundException>
		(() =>{
				using (var reader = new StreamReader("this is not a valid file path"))
					reader.ReadToEnd();
			});
	Assert.IsNotNull(exMessage);
	Assert.IsTrue(exMessage.Contains("Could not find file"));
}

In the test above, we are calling a base class method called ExpectException which, as you can see, expects an exception of type ApplicationException to be thrown. ExpectException takes an Action and will execute the action and swallow any thrown exceptions, validate an exception is actually thrown, and ensure that the thrown exception is of the specified type. It also returns the message inside the exception so just in case you have more than one code branch that throws the same type of exception but has a different message… you’re able to validate that as well as is done in the code above.

Using the ExpectException method gives you more flexibility and to continue executing code in the test. There are times when you may need to write a test that calls a method twice in order to have it throw an exception. The ExtractId method in the Part I post has logic to ensure that the Person Id is only added once so that no two people can have the same Id. That is an example of a case where you would need to call that method twice. Now, ExtractId doesn’t throw an exception on the first call but it’s just an example and if it did, you could use ExpectException in that situation to make quick work of that test.

If you don’t want to bother with checking the returned exception string, you can use the other method on that base class called ExceptionWithMsg. Here’s an example of how to use it:

// ExceptionWithMsg is "implemented in terms of" ExpectException... meaning it
// just calls ExpectException and then verifies that the exception message contains
// the textual fragment passed in.
ExceptionWithMsg<FileNotFoundException>
	(() =>{
			using (var reader = new StreamReader("this is not a valid file path"))
				reader.ReadToEnd();
		},
		"Could not find file"
	);

ExceptionWithMsg just calls ExpectException and tests the message for you… as you can see from the implementation:

protected void ExceptionWithMsg<ExceptionType>(Action action_, string exceptionMessageFragment_)
{
	Assert.IsTrue(ExpectException<ExceptionType>(action_).Contains(exceptionMessageFragment_));
}

Enjoy!

Tags: code coverage, ncover, nunit, testing, unit testing