First I need to review a test that is failing:

That test was not the last test I wrote which was the Verify Info Fields category test to return the new ControlSource property I added. The failing test was actually another test I wrote to see if two fields bound to the same table row would both report as updated in the BeforeUpdate routine. It turns out they do.

That is why I did the next test and am adding a ControlSource value to the changed field in the collection of field changes.

I could either delete the failing test because I can’t really get it to pass based on the way Access behaves, or I could validate the Access behavior and change the test name and conditions. I think in this case I’ll just go ahead and delete the test. That makes it much easier.

I also want to reiterate here that we are making design decisions based on our original goals which are that this form auditor will collect form changes for bound fields via the BeforeUpdate event. Note that we are NOT trying to get every user keystroke and we are NOT concerned with changes to unbound fields on the form. Since we have stated our goals, I’m not going to question them.

Now that I am back in a passing test condition, I am moving to the refactor stage. I am considering reorganizing the tests as my single test module is getting rather full. But I think it’s still manageable. And after reviewing my test and support functions, they look good. I think I would like to refactor the case statement inside of the FormToAudit_BeforeUpdate code though. I would like to extract the list of types as an internal variable which we can easily add to. Perhaps we could expose this to the end user so the user of this class can easily configure the watched FormAuditor Control Types.

I will do that next time.