Unit Testing in VBA

Question

Unit testing in VBA is... lacking. (What isn't lacking in VBA though?) Since I've become more interested in unit testing lately, I decided I needed something better than Debug.Assert(), so I started building this framework. Currently there is a ton of functionality missing, but since I'm new to unit testing and interfaces, I don't want to get too deep before realizing I've made a huge mistake. The code is simple, but works just fine.

I want to be able to run the output to either a file or the immediate window, so I created a simple IOutput interface that contains one subroutine.

IOutput.cls

Public Sub PrintLine(Optional ByVal object As Variant)
End Sub

And a Console class implementing it. Console uses VBPredeclaredId = True to create a default instance. The Logger class remains unimplemented for the moment.

Console.cls

Implements IOutput

Public Sub PrintLine(Optional ByVal object As Variant)
    If IsMissing(object) Then
        'newline
        Debug.Print vbNullString
    Else
        Debug.Print object
    End If
End Sub

Private Sub IOutput_PrintLine(Optional ByVal object As Variant)
    PrintLine object
End Sub

The UnitTest class then takes in an IOutput object in and stores it as a property. I need the Output stream to be available to the local project, but I don't want to expose it to external projects referencing it, so I declared it at a Friend scope (more on that later).

UnitTest.cls

Private Type TUnitTest
    Name As String
    OutStream As IOutput
    Assert As Assert
End Type

Private this As TUnitTest

Public Property Get Name() As String
    Name = this.Name
End Property

Friend Property Get OutStream() As IOutput
    Set OutStream = this.OutStream
End Property

Public Property Get Assert() As Assert
    Set Assert = this.Assert
End Property

Friend Sub Initialize(Name As String, out As IOutput)
    this.Name = Name
    Set this.OutStream = out
    Set this.Assert = New Assert
    Set this.Assert.Parent = Me
End Sub

The UnitTest creates it's own instance of the Assert object. I have a real concern here. I don't like that I have to pass in the test name along with the actual conditions I'm testing.

Assert.cls

Private Const PASS As String = "Pass"
Private Const FAIL As String = "Fail"

Private Type TAssert
    Parent As UnitTest
End Type

Private this As TAssert

Public Static Property Get Parent() As UnitTest
    Set Parent = this.Parent
End Property

Public Static Property Set Parent(ByVal Value As UnitTest)
    Set this.Parent = Value
End Property

Public Sub IsTrue(testName As String, condition As Boolean, Optional message As String)

    Dim output As String
    output = IIf(condition, PASS, FAIL)

    Report testName, output, message

End Sub

Public Sub IsFalse(testName As String, condition As Boolean, Optional message As String)
    Dim output As String
    output = IIf(condition, FAIL, PASS)

    Report testName, output, message
End Sub

Private Sub Report(testName As String, output As String, message As String)

    output = this.Parent.Name & "." & testName & ": " & output

    If message <> vbNullString Then
        output = output & ": " & message
    End If

    this.Parent.OutStream.PrintLine output
End Sub

Finally, I don't want to import all of these classes into each project I'm working on. It will be a nightmare to keep them all synced as I make changes to the VBAUnit project. So I changed their instancing to "PublicNotCreatable".

If the instancing property is PublicNotCreatable, the class behaves normally when used within the same project, but a variable can be declared of that class type in other projects. The other project cannot create a new instance of the class, but can have a variable of the class's type. To allow another project to use a new instance of the class, the project containing the class must provide a global-scope function that creates a new instance of a class and returns it to the caller. For example, suppose Project1 contains a class named Class1, whose Instancing property is PublicNotCreatable. Suppose also that Project2 references Project1.

Cpearson.com

So I have a regular *.bas module named Provider that contains this single function.

Provider.bas

Public Function New_UnitTest(Name As String, out As IOutput) As UnitTest
    Set New_UnitTest = New UnitTest
    New_UnitTest.Initialize Name, out
End Function

Then, from another project, I go just add VBAUnit to the references. (If you don't have it open, you have to click browse and navigate to the actual file.) I did just that and wrote some tests that essentially test themselves.

This is where the Friend scope comes into play. VBAUnit has access to the Initialize subroutine and to the OutputStream property, but they're not visible to any external projects.

AssertConditionTest

This code is boilerplate code. Each new test I create will need these line. Also, once I have implemented a file logger, this is where you would need to decide where to output the results to. I don't like boiler plate, but I can't think of a way to get around it. I'm way open to suggestion on this.

Private test As VBAUnit.UnitTest

Private Sub Class_Initialize()
    Set test = VBAUnit.New_UnitTest(TypeName(Me), VBAUnit.Console)
End Sub

Private Sub Class_Terminate()
    Set test = Nothing
End Sub

Followed by the actual tests.

Public Sub RunAllTests()
    IsTrueShouldPass
    IsTrueShouldFail
    IsFalseShouldPass
    IsFalseShouldFail
End Sub

Public Sub IsTrueShouldPass()
    test.Assert.IsTrue "IsTrueShouldPass", True
End Sub

Public Sub IsTrueShouldFail()
    test.Assert.IsTrue "IsTrueShouldFail", False
End Sub

Public Sub IsFalseShouldPass()
    test.Assert.IsFalse "IsFalseShouldPass", False, "with a message."
End Sub

Public Sub IsFalseShouldFail()
    test.Assert.IsFalse "IsFalseShouldFail", True, "with a message."
End Sub

Finally, in this project, we have a regular *bas. This is just kind of throw away code that we use to run the tests we're interested in.

Public Sub TestTheTests()
    Dim test As New AssertConditionTest
    test.RunAllTests
    test.IsFalseShouldPass
End Sub

To summarize:

1. Am I using interfaces in an intelligent way?
2. Is there anyway to ditch the boilerplate code in AssertConditionTest?

3. How can I avoid passing a "Test name" into each Assert statement and still get results like this? My method feels like a dirty hack at best.

   AssertConditionTest.IsTrueShouldPass: Pass
   AssertConditionTest.IsTrueShouldFail: Fail
   AssertConditionTest.IsFalseShouldPass: Pass: with a message.
   AssertConditionTest.IsFalseShouldFail: Fail: with a message.
   

4. Was it a stupid decision to make Assert it's own class and keeping a Parent UnitTest property?

Answer 1

IOutput class module (Interface)

Looking at how the interface is being used:

this.Parent.OutStream.PrintLine output

Where output is clearly a String, which makes sense. But the interface's signature doesn't reflect that, and is confusing:

Public Sub PrintLine(Optional ByVal object As Variant)

Why is the parameter optional? and why is it a Variant? ...and why is it called object? I would have expected this:

Public Sub PrintLine(ByVal output As String)

Which leads me to the implementation:

Console class module

If the parameter is a String, and isn't optional, the PrintLine implementation gets... a little bit simpler:

Option Explicit 'always. even if you're not **yet** declaring anything.
Implements IOutput

Public Sub PrintLine(ByVal output As String)
    Debug.Print output
End Sub

Private Sub IOutput_PrintLine(ByVal output As String)
    PrintLine output
End Sub

It seems your Console class was intended to be used a bit like a .net System.Console, a static class.

In the context of the IOutput interface implementation, it doesn't make sense for that class to be static, nor to have an optional parameter to its PrintLine method. However, if you encapsulate a test result in its own class...

Option Explicit

Public Enum TestOutcome
    Inconclusive
    Failed
    Succeeded
End Enum

Private Type TTestResult
    outcome As TestOutcome
    output As String
End Type

Private this As TTestResult

Public Property Get TestOutcome() As TestOutcome
    TestOutcome = this.outcome
End Property

Friend Property Let TestOutcome(ByVal value As TestOutcome)
    this.outcome = value
End Property

Public Property Get TestOutput() As String
    TestOutput = this.output
End Property

Friend Property Let TestOutput(ByVal value As String)
    this.output = value
End Property

Public Function Create(ByVal outcome As TestOutcome, ByVal output As String)

    Dim result As New TestResult
    result.TestOutcome = outcome
    result.TestOutput = output

    Set Create = result

End Function

...then I'd renamed IOutput to ITestOutput, and change the signature like this:

Public Sub WriteResult(ByVal result As TestResult)
End Sub

and Console would look ilke this:

Option Explicit
Implements ITestOutput

Public Sub WriteResult(ByVal result As TestResult)
    Debug.Print result.TestOutput
End Sub

Private Sub ITestOutput_WriteResult(ByVal result As TestResult)
    WriteResult result
End Sub

That gives WriteResult a much clearer intent than PrintLine, and doesn't stop you from implementing a WriteLine(String) method and keeping Console as a static utility class, and as a bonus you have a concept of a test result that can be inconclusive, failed or successful.

---

UnitTest class module

Mucho kudos, this is the first time I'm seeing a warranted use of the Friend keyword in VBA. This is pretty clever, and enables several things that aren't otherwise possible in VBA:

• Factories: a class can now be created and initialized with parameter values, as if created with a constructor.
• Immutability: a class can only expose getters, and be immutable from the client code's perspective.

Impressive. I wish I had realized VBAProjects could reference each other, 10 years ago!

---

Provider code module

I don't like this. I would have made it a "static" class module (with a default instance), and called it UnitTestFactory.

I don't like the method name either - again, underscores in identifiers are confusing in VBA. If that code is in a class called UnitTestFactory, the method's name could simply be Create.

I don't like that you're assigning the result, and then calling a method on that reference - it looks very awkward and would be much clearer with a result variable, and I would make the IOutput implementation/reference a property of the factory class, removing it from the method's signature:

Option Explicit
Private Type TUnitTestFactory
    TestOutput As IOutput
End Type

Private this As TUnitTestFactory

Public Property Get TestOutput() As IOutput
    Set TestOutput = this.TestOutput 
End Property

Public Property Set TestOutput(ByVal value As IOutput)
    Set this.TestOutput = value
End Property

Public Function Create(ByVal testName As String) As UnitTest
    Dim result As New UnitTest
    Set result.Initialize testName, TestOutput
    Set Create = result
End Function

---

Assert class module

I've never seen the Static keyword used like this (what's a static property in VBA anyway?), and the Parent property makes me think that class is doing more than it should. I believe the TestOutcome enum and the TestResult class I've suggested above, would be helpful here... but I don't think it's Assert's job to report the test's outcome - by keeping that responsibility at the test level, you remove the need to pass the test's name to the Assert methods.

Question is, how to do that?

I think I'd expose an event:

Public Event AssertCompleted(ByVal result As TestResult)

This would make a method like IsTrue look like this:

Public Sub IsTrue(ByVal condition As Boolean, Optional message As String)

    Dim outcome As TestOutcome
    outcome = IIf(condition, TestOutcome.Succeeded, TestOutcome.Failed)

    result = TestResult.Create(outcome, message)
    RaiseEvent AssertCompleted(result)

End Sub

For this to work, a UnitTest class only needs this - note that I'd want to call the variable assert, so I'd rename the class to TestAssert, and forfeit the default instance / static-ness of the type:

Private WithEvents assert As TestAssert

Private Sub assert_AssertCompleted(ByVal result As TestResult)
    OutStream.WriteResult result
End Sub

And... Bingo!

---

This code is boilerplate code. Each new test I create will need these line.

Don't worry about that boilerplate code. It's needed because it's the only logical place for the client code to specify an implementation for the output interface - a test might want to output to a text file, another might want to output to the immediate pane, and another might want to send the output to a listbox on a modal form... and it's really the client code's job to specify that.