Today I was struggling with trying to come up with tests for a new feature for an existing Access database.

The feature is changing the way addresses are entered for work jobs. Basically the job structure which has had embedded address fields like street, city, state, and zip, now will be able to have multiple addresses – any number.

The strategy I normally have used to develop these features is to think about the structure of the tables and how those will have to change, and consider the form and how to change the controls to accomodate the new structure.

Instead of thinking about structure today though, I considered how I would want to be able to call the addresses in code. I already have a job class which is supposed to represent a job object. It doesn’t really do that at this point, but I thought since that is the direction I’d like to take this application structure, what would having multiple addresses look like when adding them to this object.

So I wrote a test to:

• Dim and create a job object
• Call an AddAddress method on that object
• Verify that address was added to a collection of addresses in the job object.

So at this point, I haven’t written any code at all and the test won’t even compile.

My strategy is actually to also create a job address object with all the fields of data I need to define an address. This object will be able to compare itself to other job address objects to see if it has the same data (IsSame() ) is what I called it, and it will take a job address object as an argument. The AddAddress method of the job object will also take a job address object and add it to the addresses collection.

The plan is that I will use the tests to be able to build objects that will do what I tell them to do, Thinking about how I’m wanting to interact with them before I’ve created them.

I feel like this is an important idea when using test driven development and that I’ve heard it a number of times as I’ve dug in and learned from others how one would do this.

One other element to this is that I’m using RubberDuckVBA for my testing framework. Although I have really liked RubberDuckVBA, there are some disadvantages to this in my database. RubberDuck requires scanning your database to find the tests. On my complex, large database this takes about 30 – 60s. It doesn’t have to be done every time, but it has to be done a lot. This is a little heavy because being able to run tests very fast is important. I may look at some other testing frameworks as well as looking into improving the speed it takes for RubberDuck to analyze my database. Perhaps there are some settings in RubberDuck that will allow me to ignore some unneeded analysis.

We shall see. I’m looking forward to how this feature will pan out with my tests.