Practical use for NUNit 2.5's [TestCase]

Since NUnit 2.5, NUnit has supported a concept of Test Cases.  Briefly a test case to NUnit is a test which runs with a different set of parameters and can expect a different set of results.  This has the potential to minimize the amount of code required to write new test methods.

To this point I've been using standard [Test] attributes and since seeing this attribute in the documentation I've been thinking about uses for it.  Now that I've started using [TestCase] I've thought of some other uses for it cutting my test fixtures down to 1/2 or less the size previously.

Below is an simple example of the code without the [TestCase] using the traditional [Test] attribute:


The above code can be trimmed down to one function using the [TestCase] attribute:



The other beautiful thing about [TestCase]s is that it collapses each test case underneath a node which actually looks cleaner:

A couple of notes on the code above.  The compiler (C# here) will not allow you to use object initializers as a parameter to the [TestCase] so you cannot create a test function Validate(object myUser) and do something like below.

This is because the compiler will only allow constants in attributes, however if you really need something like this, NUnit allows a work around. This is documented here.

Houston TechFest Samples

Houston TechFest was a lot of fun, I attended some very interesting sessions and had the opportunity to present on the topic of NHibernate.  I have uploaded the samples and they are downloadable by clicking here.  The presentation is available here.

Unit Testing - Mocking to test Edge Cases with NHibernate

Sometimes in code you want to test edge cases, some of these can be difficult to test even with integration tests because of database constraints, etc.  This may be a business key or unique identifier (that's not a primary key)- may be enforced or not.  The key is you make an assumption that in code you want to test for.  Mocking dependencies is the key here, to create behavior that would not otherwise be possible.

Unlike the pattern illustrated by Ayende or that I added onto here, I wanted NHibernate's SessionFactory and Session objects to return data that I could not return from the database because of unique index constraints.

In this scenerio I'm returning data from the database that matches certain values and it should always return a list that contains either 0 or 1 objects otherwise it throws an exception:

Problem is that integration tests are unlikely to uncover this error with normal data and end user testing won't uncover it either.  This is simple, but I want to make certain that the exception is correctly thrown.

The only tricky part really is that after mocking the ISessionFactory & ISession objects you need to also mock each ICriteria object returned from the Session object.  So with Rhino Mocks after telling it to expect a call to CreateCriteria that returns an ICriteria, we also need to create expectations for this result calling Add and its result calling list.  This is because fluent interfaces use method chaining which makes this part a little tedious:

This allows us to now test what would actually happen if more than one Animal objects were returned.  NHibernate makes this easy because there are interfaces for pretty much every object.

FYI: this code uses Rhino Mocks, NBuilder, NUnit & NHibernate

NHibernate, Spring.Net & Dependency Injection

Inverson of Control (IoC) is a very powerful concept. The basic premise of IoC is to invert elements of your programming paradigm for flexibility and extensibility. Most procedural or OO code the linkages are hard code. Most data access code, take DAO for instance, need a handle to a connection object. Fortunately if you are using a good persistence framework like NHibernate you don't have to directly deal with the ADO Connection object as it handles that for your, however you need to efficiently manage an NHibernate Session.

How to do so is very important in ASP.Net applciations as you may have dozens of request per second and if you handle this poorly your application performance will suffer. Handle it well and you will often have better performance than straight ADO.Net applications.

Let's take two simple application layers UI and Data Layer. Our data layer contains our DAOs (data access objects) which perform direct interaction with our database and of course our UI contains all necessary user interface related code.

UI Code

The public setter that we declare here exists for dependency injection (DI), this will allow Spring.Net to set (or inject) our dependencies for us. We configure Spring to set this pages dependencies in our configuration file like the following:

This section is telling Spring that the page (Applications/Default.aspx) has a property named GenericAppSectionDao which needs to be set to a reference of an object named GenericAppSectionDao

At your applications first run (first request for a website) Spring will create all of these objects in memory for you and set them up (unless you configure them differently of course). This requires an upstart cost but saves performance with each request after the first.

Next we need to tell Spring how to create this object GenericAppSectionDao:

The first object element creates an abstract object so that Spring knows to create before the objects that are dependent on it. Next we tell Spring to create an instance of a generic class called Dao that provides basic Dao functions and we tell Spring that it's dependent upon BaseDao (again so that Spring knows to create this object after it creates its parent). The generic Dao class looks like the following:

Lastly is BaseDao which provides a public setter to set the SessionFactory with a public Getter to get the current session. This enables SessionScopes which are a good idea for web apps. BaseDao code is below

You could obviously perform the same exact methods with any IoC framework (Castle or anything else). The only difference should be the XML files. Dependency Injection (DI) is a form of IoC and reinforces best practices for writing proper unit tests because you can isolate each layer you are testing and mock its dependencies. It also facilitates AOP so you can do all sorts of stuff (transactions, logging, etc) between application layers automatically.