BDD

Global Callbacks

Global callbacks affect the execution of the entire test bundle CFC and all of its suites and specs.

beforeAll()

Executes once before all specs for the entire test bundle CFC. A great place to initialize the environment the bundle needs for testing.

component{

	function beforeAll(){
		ORMSessionClear();
		structClear( request );  
		
		// Prepare jwt driver to use cache instead of db for easier mocking
		variables.jwt.getSettings().jwt.tokenStorage.driver = "cachebox";
		variables.jwt.getSettings().jwt.tokenStorage.properties = { cacheName : "default" };

		// Logout just in case
		variables.securityService.logout(); 
	}

}

afterAll()

Executes once after all specs for the entire test bundle CFC. A great place to teardown the environment the bundle needed for testing.

run( testResults, testBox )

Executes once so it can capture all your describe and it blocks so they can be executed by a TestBox runner.

You can find the API docs for testbox and the testResults arguments here: https://s3.amazonaws.com/apidocs.ortussolutions.com/testbox/current/

Suite Callbacks

The following callbacks influence the execution of specification methods: 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( body, data )

Executes before every single spec in a single suite block and receives the currently executing spec and any data you want to bind the specification with. 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.

The body closure will receive have the following signature:

afterEach( body, data )

Executes after every single spec in a single suite block and receives the currently executing spec and any data you want to bind the specification with. 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.

The body closure will receive have the following signature:

Here are some examples:

aroundEach( body, data )

Executes around the executing spec so you can provide code that will surround the execution of the spec. It's like combining 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.

The body closure will receive have the following signature:

The 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.

Here is an example:

Life-Cycle Data Binding

You can pass in an argument called 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.

Here is a typical example:

Last updated

Was this helpful?