Why do we want to use Test Driven Development?

It is less error prone, producing better code which is more reliable and able to be verified from multiple paths.

It allows us to express our intent in the form of a test. This forces us to create a better design.

It allows for easier changes and updates to the code. We have a suite of tests that will inform us what if any intent we had no longer functions that way.

What is Test Driven Development?

1. We write a test using code to define our intent. It will fail because there is no code yet to make the test pass.
2. We write just enough code to make the test pass.
3. At this point we can refactor the code to make it better. Refactoring is changing the STRUCTURE of the code without changing the BEHAVIOR of the code. In other words, the code will continue to make the original intent check PASS.

Ok, that sounds good you say. Now what?

TDD in Microsoft Access using VBA and RubberDuckVBA

Ok, so I will admit here that I have not done production Test Driven Development. I want to. This journey I am beginning will likely be fraught with mistakes. I have so far used the Unit Testing functionality in RubberDuckVBA to start creating tests for some library routines that were written for Access JumpStart.

If you’d like to join me on the journey, I am going to start by attempting to design a basic Access Form Auditing tool that will gather the changed fields to a bound form and allow them to be stored somewhere. I am envisioning probably having at least 2 interfaces: one that captures the form changes and another that writes the changes to a log or database table. These interfaces will allow us to have a set of multiple potential classes to modify what data we actually capture and another set of classes that can write / output to various media (like a log file, a database table, or an email for example).

I am currently using Access 365 and RubberDuckVBA 2.5.9 (main)

Buckle up, I hope we all enjoy the ride!