Kent Beck, a father figure when it comes to Test Driven Development for many people, has an article on “Canon TDD”
Canon TDD – by Kent Beck – Software Design: Tidy First? (substack.com)

In this article, as I mentioned yesterday, the first thing that he lists in the process of how to do TDD is to make a list of tests.

I have thus far failed to do so. I started just planning AND writing a single test as I went into the Failing Test phase.

Really what I should have done was have at least a list of possible tests and pick from which one I want to do next. Frankly this sounds a lot better than what I was doing. It was hard to think up a new thing to test whenever I got to that phase.

So I’m spending a little time right now to come up with more possible tests, not actually writing them, but writing down what I actually might want to test for this Form Auditor.

A List:

• 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

Wow, ok, so I cheated a little because I started thinking about a particular form auditing class I already have built without TDD. I noticed right away that my brain probably isn’t working quite right as these are more behavior type requirements rather than a list of tests, however, I’m thinking this is the direction I probably want to go in. I want to be able to categorize my tests and these could definitely provide categories and series of tests for me to think about and develop.

I’m considering that a success. I will stick that list into the comments of another module for reference.

So far I have 5 tests that are still standing at the moment after the smoke has cleared. GivenFormAuditor:

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

So far I have categorized these as “Count Changes” tests. I think they are much smaller in scope than the list of possible test subjects I have above. I guess we will see how this starts to further develop: tomorrow…