I now have a real-world scenario for requirements for this class. Requirements are coming from customer requests and then interpreted into a list for myself. Test Driven Development then takes requirements and you translate them into tests (one at a time). Just because I have a list of customer requirements, I need to resist the temptation to try to write a whole bunch of tests right away. The problem with doing something like that is that you are already baking assumptions and structures of the code itself that I want to be more fluid. I want to write one test at a time and write the code to make that test pass.

In my case, I have built a test form and test table to bind the form to. I am modifying this along with the code as I need to in order to make the tests pass.

Now, here is my current list of requirements up to this point in the development of this class. I’m going to present this original list, which is set up as comments in a module in the app:

'A list of things to help create tests
'
'Easily load the form auditor object into a form.
'
'The form auditor keeps track of any changes to the form as the form is changed
'
'If the form changes are canceled before we find them (BeforeUpdate is canceled 
' before finding changes) then don't record any changes
'
'If the form changes are canceled after we find them by a subsequent BeforeUpdate
' hooked call, we don't want those changes to appear in the list either.
'
'OR, instead of the above, maybe we do track the changes anyway and just have an
' indication of whether the update was canceled or not.
'
'Test whether this is a bound form.
'
'Test which controls are bound and whether they were updated.
'
'Maybe have a list of non-bound controls to make the user of this class aware of
' things that aren't being tracked
'
'Consider if there are any good ways to track them (control events)
'
'Make sure the auditor descends into subform controls and audits those forms as well
'
'Create different change reports via a single change report interface.
'
'Report for an end user
'
'Report for the developer
'
'Report for a log format to a database
'
'Report for a log format to a text string

And now I am going to consider the implications of my customer’s request.

All fields on the form including the status field should be tracked in the log window.

The status field should not trigger an automated email.

– Customer

I need to interpret this based on what I already know of the application and from the customer’s point of view.

My customer is not a programmer. When he says “all fields”, he really means the fields that are visible. The auditor is also currently not programmed to track changes that get made to other fields as a side effect of a change the user makes to one particular field. For example, changing the status field on the main form, a continuous sub form can potentially have fields updated on each line because each line can have it’s own status.

So I can start updating the requirements from a technical standpoint for myself as a programmer.

• All visible fields on the form and it’s sub forms [that are editable?] should have changes logged after each user edit of the form.
• I will need to be able to make sure I am writing certain changes to the user log table, but also be able to ignore certain logged fields when triggering email deliveries.
• I also want to actually track all changes visible or invisible for an internal debug log for myself.

Now, I see that I have a question in my first bullet point. At this point, I would review the form the customer is referring to and see if all editable fields would be approriate for his definition of “all fields”. If I have any uncertainty, I will go back to the customer and ask for clarification on “all fields”. Note that I am not just assuming “all fields” means the same thing to the customer and myself in this case. From a developer standpoint “all fields” might mean every updatable control on a form and subforms.

After considering the question I had a little more, I think that I would like all bound fields to get any changes logged.

I think I will need to store the state of every bound field prior to a user update, then compare after a user action. Another consideration could be buttons on the form that might trigger an update to the underlying dataset. I’m thinking of adding the following to my list:

'Default to checking bound fields for changes, also on sub forms possibly for
' multiple records and record deletions and additions
'
'Allow other non-bound controls to be added manually for checking bound fields
' for changes. (Like buttons that will have effects on bound fields)
'
'We will want to check for changes against a persistently stored dataset (not
' in memory in case of VBA crash or reset)
'
'The persistently stored dataset should be updated as bound fields change

Well, this looks like it is going to drive some significant changes to my original form auditing vision as it is going to be based on the underlying source data rather than simply catching BeforeUpdate and AfterUpdate form events. This should get interesting. I’ll start to unravel this further in my next TDD installment.