Access JumpStart 2.0 | Blog

A Rapid Development Framework for Microsoft Access

Do I want the Auditor to make sure that if the control is empty with Null or empty with a 0 length string it treats them the same? Or do I want the Auditor to do strict typing?

Yesterday’s Article

I have decided that the Form Auditor class itself will do strict typing. Meaning I want to differentiate between null and an empty string as well as changes in case. So my next tests will focus on that.

I know already that an empty string compared with a null will crash my current tests, so I am going to write the test to crash and burn!!! Mwah-hah-hah!

'@TestMethod("Count Changes")
Private Sub WhenFieldChangesFromNullToEmptyStringThenReturnOneEntryListOfChanges()
    Dim testFormAuditor As FormAuditor
    Dim testCollection As New Collection
    ChangeTestText Null
    Set testFormAuditor = New FormAuditor
    ChangeTestText ""
    Set testCollection = testFormAuditor.ListOfChanges
    Assert.AreEqual CLng(1), testCollection.Count
End Sub

Now I’m not sure I mentioned this before, but whenever you run tests in RubberDuck, you need to refresh it. This re-analyzes your code and populates new tests in the Testing Window. So I’m doing a RubberDuck refresh then running all unit tests from the Test Explorer window. I have a Toolbar in my VBE as shown below where I can refresh by clicking the arrows.

Then it goes through some status messages and it’s done when it looks like this:

There is also another refresh button in the Test Explorer. It does the same thing. It’s in the upper right corner of the Test Explorer tool bar:

So now, I will click Run and choose All Tests which is normally what I do because each time you refresh RubberDuck, it resets all the test results:

In this case I get a compiler error “Invalid Use of Null” and if I hit debug it takes me to the line in the test where I’m trying to pass null to the ChangeTestText function. I think I can get this to pass simply by changing the function to accept a Variant type of variable rather than a string:

Private Sub ChangeTestText(Optional NewValue As String = "")

Becomes:

Private Sub ChangeTestText(Optional NewValue As Variant = "")

Let’s see if this is enough.

We are closer now, but still failing. It does compile now. I think perhaps the comparison in our function now needs to be looked at:

Private Sub FormToAudit_BeforeUpdate(Cancel As Integer)
    If FormToAudit.TestText.OldValue <> FormToAudit.TestText.Value Then
        pListOfChanges.Add FormToAudit.TestText.Value
    End If
End Sub

If I put a break in my test I can step through it and see how the text form field handles the null <> “” situation. I suspect it is simply translating both to a zero length string in the OldValue and Value properties. Looking at the comparisons in my Immediate Window I see two problems:

?FormToAudit.TestText.OldValue
Null
?FormToAudit.TestText.Value
New Thing 8.657503E-02

One being that the new value didn’t get set to “”, and the second problem being that it did not consider Null any different than the new random value. Two problems we can tackle in our next episode.