Access JumpStart 2.0 | Blog

A Rapid Development Framework for Microsoft Access

First things first, I am continuing to work on the new test and adding code so it will actually be testing the class user expectations.

I would expect that if I create this Form Auditor class and don’t have any changes to any forms, I would expect that any results returned would either give me an error or just an empty or zero length object.

I think that I want the user to be able to return a change object that is empty.

So let’s add a new Public Property to our FormAuditor class which will return a dictionary object that is empty.

I’m already thinking about the dictionary object. Maybe I don’t want something exactly like that. So instead of a dictionary object, I’m going to consider a little bit more of the design. Maybe I do want a dictionary, maybe not.

So as a consumer of this class, what kind of information do I want to see. Maybe we want this FormAuditor to be a standalone object that listens to any particular form I pass and I keep a collection of forms internally. In that case, I’d probably want the form name, although the form name could theoretically be the same for multiple forms due to the fact that a technique could be used to open multiple instances of the same form. If someone does that, I’d like this auditor to still be able to differentiate the forms. So perhaps I could create another class to store data for a particular form. I’ll just keep this idea in the back of my head. This actually would be a way to use a dictionary of Forms, the index of the dictionary being the reference to the form object being audited.

Ok, so I’ll stick with the dictionary at the moment.

Here’s the test:

'@TestMethod("FormAuditor")
Private Sub GivenFormAuditorWhenNoFormIsChangedThenAuditorReturnsEmptyListOfChanges()
    Dim testFormAuditor As New FormAuditor
    Dim testDictionary As New Scripting.Dictionary
    Set testDictionary = testFormAuditor.ListOfChanges
    Assert.AreEqual 0, testDictionary.Count
End Sub

I updated the name of my test a little bit. Yes, the name is long. I use long names of things in VBA to try to leave no questions. I think it ultimately allows more readable code and self documenting systems.

All righty. Now we have a failing test. Next time I’ll make it pass. Should be pretty simple.