Ok, so in the last installment, I told myself to stop and review this. I think my last couple of tests were going down the wrong path.

Let me review what I am trying to achieve again:

Here’s what I said in post 1:

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).

TDD – 001 – the beginning | Access JumpStart

And what I said about the design in post 2:

I want a class I can instantiate on any bound form, observe the changes the user (or system?) is making and have a list of those changes I can iterate over and output something.

TDD – 002 – initial design and first test | Access JumpStart

So far I have a Form Listener Class. It has the following public methods:

• Setup (theForm As Access.Form)
• TimesFieldChanged (theFieldName As String)

And a property:

• BeforeUpdateTriggered

Setup is a method that will likely remain as I will need to configure the listener to hear the form.

I think now what I really want is not to try to get the Form Listener to hold all the info, but simply to iterate through the bound fields on the form and add any field that has changed data to a variable that gets passed to an event it will trigger.

Considering this, I may pretty much be done with tests to perform on the Listener. It is hooked into the BeforeUpdate event of the form. From a usage standpoint, I don’t need to know whether the BeforeUpdate event was triggered or how many times. In fact, it sounds like I want to delete the BeforeUpdateTriggered property and TimesFieldChanged method, and hence delete the tests relating to those.

Instead, I think I may want to create a new Class that will receive fields from the listener and store them internally. So this new class would also need:

• Setup method to configure the form and instantiate a form listener on it.
• Handle the FormListener’s event to receive what fields changed.

Well, that is wracking my brain a bit. Let’s see, so the FormListener is simply listening. Now it does have to do a couple things. Like iterate over all the form fields and prepare some kind of object (like a collection or an array, or a dictionary) to pass all the changes being made. That is feeling to me like maybe another object inside of the form listener. Something I can test. In order to do all these tests, we must have an object with public methods and properties. This Form Iterator will need to look at OldValue and Value properties of many of the fields on the form.

That’s enough for today, looking forward to tomorrow’s post.