A simple, no-boilerplate unit testing framework for VBA and VB6.
Not all code is testable. Code with side-effects on global state cannot be tested; code that accesses a file system, a network, or that needs a database connection, cannot be tested. However, techniques such as stubbing and mocking exist to make unit testing possible for code that is written against abstractions - in object-oriented programming (OOP), code that adheres to the S.O.L.I.D. principles is testable code. VBA procedures that manipulate worksheets? Not so much... for now anyway.
Excel user-defined functions (UDF) that take in all their inputs as parameters are pure functions, and pure functions can (and arguably should!) be unit-tested. VBA and VB6 applications that use class modules and adhere to the language-agnostic principles that guide OOP design, can use Rubberduck to write a well-organised, boilerplate-free test suite.
If you are just starting to learn VBA, unit testing may be too advanced for now, but know that everything you learn while learning unit testing in VBA will be applicable all along your journey into programming, and that can only be a very good thing.
The feature that started it all. Some of this code is a direct port of the original VBA testing tool written by Christopher McClellan and Mathieu Guindon, that became Rubberduck.
This tab lists a number of feature items worth mentioning. To modify this content, an edit must be submitted from the content admin sub-site.
Rubberduck gives you two ways to assert unit tests: a "permissive" implementation that compares values similar to how VBA does, and a strict implementation that enforces data type equality (e.g. a Long cannot equal an Integer).