Introduction
Unit testing a great way of ensuring quality in your class method calls. It gives you confidence that as you refactor your code, all works as you originally intended. Following the test driven development approach to writing your unit tests before you write your code leads to both better domain knowledge, better quality code and a more usable API for calling clients to use.
Recently I have been working on a project whose design goals were best achieved through an event driven programming model. An event driven pattern most closely matched the way in which the business worked in real life, and the results have been a very lean and effective model for the business to use.
I wanted to write unit tests to check that the events had fired as expected when a particular method was called, with certain arguments passed in. It was vital that these events were working as expected, as the whole behavior of the application would be effected if the event model did not function properly.
The problem
NUnit (and other variants of) allow you to write unit test methods, either expecting the code to run without exception, or, the method to return an expected exception. You write an Assert statement, usually to check that a condition is true (such as a method return). So how you check that a single method call has fired all the events you expect? The method may return without exception, but that doesn’t tell you that the events have been fired as a result.
Pair programming to get to the answer
I came across the answer to my problem during a pair programming session with one of my team members. I am mentioning this, because I am certain I would not have been able to solve the problem so elegantly if I had been on my own; stepping back from the keyboard allowed me to see the problem much more clearly.
The solution
The pattern to the solution is shown in the diagram below:
It involves providing a extra layer of indirection between the NUnit test fixture client (shown on the left) and the business logic class (MyBusinessProcess). To facilitate code reuse, the pattern uses a delegate which can be evaluated (using the CheckProcessEvents method) to check for Boolean values which indicate whether each event has been fired as expected.
The order of play is:
- NUnit calls DoUnitTest on the test fixture class
- DoUnitTest calls test unit process DoProcess method, which has its events wired up for MyBusinessProcess evemts
- The DoProcess method calls ExecuteProcess method on MyProcess which in turn fires some of its events.
- The DoUnitTest method delegates evaluating the business process events to the CheckProcessEvents method method, and Asserts the unit test if the events run as expected.