TestBox supports the concept of assertions to allow for validations and for legacy tests. We encourage developers to use our BDD expectations as they are more readable and fun to use (Yes, fun I said!).
The assertions are modeled in the class testbox.system.Assertion, so you can visit the API for the latest assertions available. Each test bundle will receive a variable called $assert which represents the assertions object. Here are some common assertion methods:
TestBox comes with a plethora of assertions that cover what we believe are common scenarios. However, we recommend that you create custom assertions that meet your needs and criteria so that you can avoid duplication and have re-usability. A custom assertion function can receive any amount of arguments but it must use the fail() method in order to fail an assertion or just return true or void for passing.
Here is an example:
You can register assertion functions in several ways within TestBox, but we always recommend that you register them inside of the beforeTests() or setup() life-cycle method blocks, so they are only inserted once.
You can pass a structure of key/value pairs of the assertions you would like to register. The key is the name of the assertion function and the value is the closure function representation.
After it is registered, then you can just use it out of the $assert object it got mixed into.
You can also register more than 1 CFC by using a list or an array:
Here is the custom assertions CFC source:
You can also store a of assertions (Yes, I said plethora), in a CFC and register that as the assertions via its instantiation path. This provides much more flexibility and re-usability for your projects.