Scott Hanselman has been experimenting with Ruby, Watir, and NUnit. His goal is what all of us web guys are after, a better way to perform unit testing of the web interface. We have NUnit to test all of our business objects, data acess code, and controller logic but we don’t have any real good options for performing unit testing on the web presentation layer. Scott developed a WaitrAssert class for integrating Waitr into NUnit which he uses to do all the testing within his application. Definitely cool stuff…
I've recently written a series of posts on the process of automating the unit testing of CRUD operations on business objects.
In future posts I'll dive into some of the details which I didn't go into such as how to set the allowable values for a property, how to ignore a property when comparing objects, how to set a property value as unique, as well as how to manage relationships among objects. Look for a zip file containing a running example in the next couple of days.
In Part 1 of Automating Unit Testing with a Base Class I provided a brief introduction to Unit Testing, provided an overview of the problems that unit testing business objects present, and briefly discussed why I include the database in my unit tests. In part 2, I provided an overview of the process I've followed in testing the CRUD operations of my business objects. In this final installment I'm going to discuss how I've simplified the testing of basic CRUD operations on my business objects by creating a base class for my business object unit tests.
Let's Review
Before moving on to the solution I'd like to quickly review the process I follow in testing the CRUD operations on my business objects.
Create
- Instantiate an instance of the object
- Set the properties of the object with valid values.
- Call the Save() method on the object, checking that the save succeeds.
Read
- Do Create.
- Retrieve the object out of the data store and check that the values of the saved object equal the values pulled from the data store.
Update
- Do Read
- Change the properties of the object.
- Call the Save() method on the object.
- Retrieve the object out of the data store and check that the values of the updated object equal the values pulled from the data store.
Delete
- Do Create
- Call Delete() on the object.
- Try reading the object back out of the data store and ensure we get a null object (since its deleted).
See Part 2 for the code representation of the above
What can we Automate?
Over the past year I've written a lot of unit tests for the CRUD operations on my business objects. A couple months ago I was working on a moderately sized .NET project coding away, writing failing tests for each of my CRUD operations, writing the code to make the tests past, and refactoring my way to cleaner code. The process was feeling pretty good, except for one thing. I seemed to be writing the same code over and over. Duplication is bad, so why do I allow myself to write 50 test classes with almost identical logic for testing the CRUD operations on my objects? I try to follow the Don't Repeat Yourself principle that Dave Thomas and Andy Hunt present in The Pragm