Ok, time to review the list and pick something else to start testing. I did spend some time in the article posted by Kent Beck last time: Canon TDD – by Kent Beck – Software Design: Tidy First? (substack.com)

I’m going to have to review it some more and probably grab his book and start reading it too. The test order chosen can lead to different ways the development of the system might go. Also, the tests sometimes might be recommending by your inability to create tests that you chose the wrong path and you should start over. Yikes. Well I guess I’m slightly ahead of the curve since I already did that once. I hope the 3 digits I chose will be enough “tomatoes” to get to the goal (each session is a tomato of time or 25 minutes as I have chosen). I guess I have to 999 and then I could always go hex and get more… 😛

Anyway, let me review the list and look for what I want to test next:

• 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 my current list of tests:

1. WhenNoFieldIsChangedThenReturnEmptyListOfChanges
2. WhenOneFieldIsChangedThenReturnSingleListOfChanges
3. WhenTwoFieldsAreChangedThenReturnTwoEntryListOfChanges
4. WhenOneFieldIsChangedToSameValueThenReturnNoListOfChanges
5. WhenFieldChangesFromNullToEmptyStringThenReturnOneEntryListOfChanges

Ok, so I’m currently in: “The form auditor keeps track of any changes to the form as the form is changed“

My tests so far are tracking how many objects in a collection will be returned by the ListOfChanges method of the FormAuditor object. I’m going to keep going down the track now and test what the text field value is before and after the event.

I am really wanting to use a dictionary for some reason. I guess I like the idea of a hashtable of field names. This seems like a quick win. Due to the subforms later though, I probably also want to grab the form name that the control lives on in case there are repeats. Although I also need to consider, what if the same subform name is reused in multiple instances in a form. Is that even possible? Perhaps I could just store as part of the dictionary, a reference to the actual form being audited. Then I could compare the instances and make sure they were different.

Yikes: Can the same subform be used on a form multiple times without issues? (microsoft.com)

Seems like a rat’s nest. I guess the initial aspect of the Form Auditor only has to be aware of one form at a time though, now that I’m thinking about it. There could be a new Form Auditor instance for every subform which could get created at initialization. So I’ll think about that more later. There is actually a test case for this already in my list and I didn’t choose that one.

Ok, so I’m going to start with a dictionary of field names for the active form and go from there. I’m also going to want information on when the event triggered, and whether the overall event was canceled or not. So I think I will make a dictionary for the top level, and have another dictionary for the “FieldChanges”.

So my next test will be to make a single change to a field’s value from “start” to “end” and verify that the name of that field and those values are returned.

All right! Looking forward to coding that test next time!