Steve Eichert

Unit testing is quickly gaining traction within the .NET community.  By unit testing business objects developers are finding they are able to reduce the number of bugs they write, and improve the overall design of their applications.  The benefits of unit testing are well documented; however, unit testing objects doesn’t come free of charge.  Writing unit tests for each method of a business object is a time consuming task and often requires a lot of repetitive code.  This article discusses a method that can help reduce the leg work required to create a suite of unit tests for testing basic CRUD (create, read, update, delete) operations on business objects.  Removing the overhead of writing individual tests for each of the CRUD operations allows the unit testing effort to be focused on the area that it's most needed, the business logic of the application.

Note: This article focuses on automating the unit testing of objects in a domain model and ignores how some of the techniques could be used to test an application using a manager/service model.  Many of the ideas can also be applied to applications using the service model which I'll look to address in future postings/articles.

Before getting too far, let's briefly overview what unit testing encompasses.  Unit testing is the process of creating a set of automated tests that validate that the individual components (units) of an application behave as expected.  Each unit is tested via a test class, a “unit test.”  The unit test performs a series of assert’s to ensure each method exposed publicly provides the correct behavior when it’s provided different sets of information. 

Test driven development focuses on using unit tests to drive the development of software.  Rather then testing objects after they have been written, the tests for each class are written before the actual implementation.  Test driven development forces developers to design their applications with the users of the API in mind.  It results in a de-coupled API that is clearly focused on the tasks that the end developer will need to accomplish.

Creating automated tests for the objects within an application helps reduce bugs, and can result in a cleaner overall design for the application.  Both good things.

The Problem Area

Although unit testing provides many benefits it doesn’t come free of charge.  Unit testing objects takes time.  Over the course of a project unit testing will often end up saving time, however, the up front costs can’t be ignored.  Writing unit tests for every method of every business objects is time consuming and can involve a lot of repetitive coding. 

Each business object has a common set of operations.  These operations are typically referred to as CRUD (Create, Read, Update, Delete).  Each object needs to be able to be saved to the data store, read out of the data store, updated, and removed from the data store.  Every business object implements these features, and should have a unit tests validating that each of these operations performs as expected.  Although the implementation of each operation is similar across all business objects, it is different enough to require a separate unit test method for every single business object.  In a large application this adds hundreds of methods for testing a set of functionality which is consistent across all of our objects.  This forces us to write a lot of repetitive code.  But should it?

Why test with the database?

Before moving on to address whether testing the basic CRUD operations on business objects should require a lot of repetitive coding let me first address the age old question: “Should a database be included in my unit tests?” 

Many developers within the Unit Testing / Test Driven Development (TDD) community believe that unit tests should not include the database.  Including the database in unit testing and TDD efforts does slow down the process and can interrupt our coding “flow“, however it has benefits which can be extremely valuable:

• Validate the stored procedures function as expected.

Including the database has disadvantages as well:

• Have to spend more time thinking about how to fit the database in with the unit tests.
• Need to write scripts OR DTS packages to setup the database in a clean state.
• Need to worry about cleanup of any data inserted during the running of the unit tests.
• The tests will take longer to run when it’s running against the real database rather then just a Mock object.

Over the last couple of years I’ve stood on both sides.  Early on I didn’t know any better so included the database in every aspect of my testing.  As I became more familiar with Unit Testing and TDD I slowly began introducing Mock Objects, and stub methods into my unit tests.  By reducing the interaction with the database I was able to increase the quality of my designs and get into more of a groove as I wrote my test classes.  Unfortunately, I also started noticing more problems with my database and stored procedures.  Usually the problem wasn’t significant, a missing parameter on a stored parameter or an improperly set default value for a column.  Clearly the database needed to be included in my testing process, but how?

Next up: How do we automate our tests, and how does this compare to how we currently test our business objects