Getting the Most Out of Your Unit Tests

Whilst recently viewing the code coverage results from one of our applications, I was looking for areas which contained poor code coverage to see if there was any way to improve code coverage in those areas. One area that can be difficult to unit test are exception conditions. If you are implementing structured exception handling using

Hide Copy Code

try / catch

blocks, then it can be challenging to unit test the code contained within the catch block. Although most (if not all) unit testing frameworks contain mechanisms for testing exceptions, it can be difficult to set up the conditions that will trigger an exception.

I tend to follow the rule of thumb that states “If you aren’t going to handle an exception then don’t catch it”. There is little point catching an exception if all your code does is throw the exception back up the call stack. In the case of my ASP.NET WebAPI application, all the controllers contain structured exception handling. This is the last chance saloon to catch any exceptions before handing control back to the client, so it makes sense to catch exceptions on the part of the application exposed to the client. I also log all exceptions so that I can later diagnose them.

I also catch exceptions in my data layer. I implement a retry mechansim on those methods that do not use the Azure Service Bus (a service bus architecture will automatically implement a retry mechanism if an exception is thrown and place the request back on the service bus queue where it can be re-tried again). These are the only specific areas of the application where I have implemented structured exception handling.

When implementing the business layer, I wanted to ensure I could unit test the various methods without the data layer methods having to actually connect to the data itself. So I implemented an architecture that allowed this from the ground up. My business layer classes contain a reference to an interface that implements the data handling methods. My unit tests implement this interface with implementations of the various methods under test. This is then injected into the constructor of the business layer class at run time by the unit tests. My business layer class contains a default constructor which instantiates the default SQL Server data layer class. It also contains a constructor which accepts an instance of the interface containing the definitions of methods that have been implemented specifically for unit testing. So with good design from the very outset it is perfectly possible to unit test your entire business layer using constructor injection.

This is the definition of the SQL Server data class. Notice it implements the IMyInterface interface.

Hide Copy Code

public class MyDataClass: BaseData, IMyInterface
{
// implement data methods here
}

This is the definition of the unit test data class. Notice it also implements the IMyInterface interface.

Hide Copy Code

public class MyUnitTestDataClass: IMyInterface
{
// implement data methods here
}

Here is the definition of the IMyInterface interface.

Hide Copy Code

public interface IMyInterface
{
List<Mileage> GetPreviousMileages(int driverId);
List<Driver> GetDriverVehicles(int driverId);
}

The business layer class then implements constructor injection so that it can accept either a concrete instance of the unit test implementation or the SQL Server implementation.

Hide Copy Code

public class MyBusinessService
{
private readonly IMyInterface _data;
/// <summary>
/// If no data class is passed to the constructor then use the default data class.
/// </summary>
public MyBusinessService()
{
this._data = new MyDataClass();
}
/// <summary>
/// Allow unit testing fixtures to implement their own version of the data class
/// which can be injected via the constructor.
/// </summary>
/// <param name="data"></param>
public MyBusinessService(IMyInterface data)
{
this._data = data;
}
}

The unit tests instantiate the business layer by injecting a unit test specific instance of the interface, as in the following example.

Hide Copy Code

[TestMethod]
public void MyTestMethods()
{
//Act
MyBusinessService service = new MyBusinessService(new MyUnitTestDataClass()); //inject your unit test class here

//Arrange
var result = service.GetPreviousMileages(123);
//Assert
Assert.IsNotNull(result);
Assert.IsTrue(result.Any());
}

I will delve more into unit testing in future articles as it’s an area where huge benefits can be made to increasing the quality of the software. It also forces you to write code in such a way that it is unit testable in the first place, and this in itself is a good reason to implement unit testing within a development team. If you’re not writing unit tests, you’re doing it wrong.

A father, cyclist, vegetarian, atheist, geek and multiple award winning technical author. Loves real ale, fine wine and good music. All round decent chap.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store