I’ve been a relatively recent newcomer into Test Driven Development, only starting to implement it into my projects and been working on learning it since 2023 or so.

Today, my Access adventuring leads me to work on changing the behavior of custom rule of the system. One type of record historically has had to have it’s quantities aggregated over a higher level of grouping than other types of records. This has now been changed so that the quantities should be aggregated the same.

Over the 7 or 8 years I’ve been working with this customer, I have inserted little conditional code snippets here and there throughout the system to accomodate the difference, and now that it is gone, I’m having to go hunt for all of those and remove them, hoping and praying that it will not negatively affect other parts of the system.

Inevitably it has and so then it’s a matter of figuring out, wait, was that already broken or was this because of a change I made? Or is there some other conditional code snippet that I missed.

These code snippets are baked in everywhere, the code, some SQL queries in Access, some SQL queries on the SQL server. It’s not TOO bad given that I have excellent find and replace tools, but it is not as easy as I’d hoped.

In addition there is another area of the system that also relies on the special aggregation and I will need to add a new aggregation level for another table that gets compared to the new way the other table’s record gets aggregated.

So why do I bring up TDD? Because I feel that if I had better code coverage this would not be as much of an issue. I guess it gives me the opportunity to add more tests, but I don’t feel like I have enough time to create tests to cover everything I need to fix.

Ok, well thanks for indulging me as I came up for air! Happy coding and may you begin to consider TDD and unit testing your code if you have not in the past.