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:
- WhenNoFieldIsChangedThenReturnEmptyListOfChanges
- WhenOneFieldIsChangedThenReturnSingleListOfChanges
- WhenTwoFieldsAreChangedThenReturnTwoEntryListOfChanges
- WhenOneFieldIsChangedToSameValueThenReturnNoListOfChanges
- 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…