I’ve been sick for the past two days, and kept getting too tired to create a post for the day. So I did what I could for my clients first, then slept. 😛

I’m feeling much better today, so I’m back in the messaging chair. I ended up scrapping my idea from yesterday:

Automated testing strategy – TDD – Unit Testing | Access JumpStart

I created a couple of the tests to start adding and deleting addresses from a Job class that represented a job. They worked fine, but it was driving me to a very heavy coding solution to mimic the behavior of a subform. I ended up not using the multi address feature from the Job class and for expediency’s sake to just actually use a subform. If you have an object that already does all the behavior you need (add / remove addresses, select them, edit them) then I just wanted to do that.

Of course, there’s really nothing to test now for that subform. The subform control is a drop-in black box with little to no code needed to provide most of the features.

What I realized through this exercise is that the requirement to provide multiple addresses was better done for the Access form interface through updating the tables, then modifying the form by adding the linked subform to manage it.

Ok, so what kind of things would I need to use code for and tests? One answer to this would be business logic that can be separated easily from the form. So, let’s say the customer always wants at least one address. I could move the logic for that into the Jobs class. Something like a function like: DoesJobHaveAtLeastOneAddress()

Maybe that would be a boolean. Then I would want to create a form controller class that would maybe listen to the Form Close event and cancel it if the function was false and display a message to the user that the condition is preventing them from closing the form and to pretty please create at least one address so the job can be valid and saved.

The ultimate answer to the question posed of when to do TDD vs simple form design I believe (so far in my TDD journey) is:

1. Do TDD when adding lots of VBA code that does not control the form design (like position of things, the “view” part of the application so to speak).
2. Don’t do TDD when you are adding form controls and can manage behavior of the form with properties and minimal use of VBA code.

Let me know how you might answer this question…