describe
and it
blocks so they can be executed by a TestBox runner. testbox
and the testResults
arguments here: https://s3.amazonaws.com/apidocs.ortussolutions.com/testbox/current/​it(), then()
. The great flexibility of the BDD approach is that it allows you to nest describe
, feature
, story
, given
, scenario
, when
suite blocks to create very human readable and organized documentation for your tests. Each suite block can have its own life-cycle methods as well. Not only that, if they are nested, TestBox will walk the tree and call each beforeEach()
and afterEach()
in the order you declare them.beforeEach()
operations and out of the tree (from the innermost suite) for afterEach()
operations.body
is a closure/lambda that will fire and the data
argument is a way to bind the life-cycle method with a struct of data that can flow down to specs.body
closure will receive have the following signature:body
is a closure/lambda that will fire and the data
argument is a way to bind the life-cycle method with a struct of data that can flow down to specs.body
closure will receive have the following signature:before
and after
in a single operation. The body
is a closure/lambda that will fire and the data
argument is a way to bind the life-cycle method with a struct of data that can flow down to specs. This is the only way you can use CFML constructs that wrap around code like: try/catch, transaction, for, while, etc.body
closure will receive have the following signature:spec
is the currently executing specification, the suite
is the suite this life-cycle is embedded in and data
is the data binding, if any.data
, which is a struct
of dynamic data, to all life-cycle methods. This is useful when creating dynamic suites and specifications. This data
will then be passed into the executing body for each life-cycle method for you.