Back 6 months ago I was asked to add new fields to check for the validity of a line item on an order.

This caused me to go through a rather extensive process to break dependencies on an Access form so that I could test it without having to launch the form and build an entire scenario with an order. I just wanted to say, this is the line data, is it valid or not? That was the test I created and then I worked on implementing that test.

Here is the string of related messages:

TDD – 073 – This Might Get Messy! | Access JumpStart

TDD – 074 – Breaking Dependencies for Testing | Access JumpStart

TDD – 075 – Breaking Dependencies for Testing (part 2) | Access JumpStart

TDD – 076 – Breaking Dependencies for Testing (part 3) | Access JumpStart

TDD – 077 – Breaking Dependencies for Testing (part 4) | Access JumpStart

After completing that series of breaking dependencies, I was asked to make another field required. This previous work made it really easy to add a new test for the new field for the IsLineValid function. I had to update a couple of other tests I had made for valid lines later on that didn’t include this field, but it was trivial once I had written a test to fail if the field wasn’t there.

I just made that pass, and then I immediately saw that break 4 other tests and I just had to add the new field to make sure those tests would validate properly as well.

It was easy and now I have tests.

However, my work was not complete. Although I have tests for this one function, there are other places where I need to add the validation conditions:

• One in a SQL statement for the order validation
• One in the conditional formatting for the field on the line items form so it turns pink if it’s required
• Another spot to update an error message when the line was invalid explaining to the user why
• I needed to create an object for the new field as part of the validation events in the form itself so that changing the field would trigger a reload to set the validity flag record for the line.

With all of those other areas needed for the validation, a success here is that I was able to look at the original changes in my versioning system so I could find exactly where I needed to add the additional code. But the bad news is that all of that stuff is still linked to the form and was not part of the tests I had written so far.

But, this is why test driven development can be very beneficial. It makes me think about why the code is where it is. Is there a way to consolidate all this validation code into one function? Is there a way to link all of these together so that I only need to test one central hub that determines linen validity?

This can really help me truly simplify the system if I can answer these questions and move in a direction where 1 validation routine could be used in all these situations that require it.

I clearly have more dependencies that would likely need to be broken, and procedures to unify them, like SQL statements that have to do with the tables. There are also things to consider like speed.

If I were to change the conditional formatting function to use a user defined function for example, I know that would bog down my line items form and make it practically unusable after adding 8 or 9 lines, and the form regularly needs to process that many lines.

I don’t need to do all this immediately, since I do have to consider getting this done quickly for the customer as well, but looking at all this and taking it into consideration, I can begin to change small things here and there to try to move the direction I need to go. After all, Test Driven Development is built on making very small changes!