Team TestBox is proud to bring our latest release to fruition, v2.2.0. This release includes a collection of fixes but also several new cool features like gherkins-like syntax support, spec data binding, test listeners and much more. We invite you to read our updated documentation book and the what's new page for an in-depth overview of the release.
You can also very easily get started or update your project with TestBox via CommandBox CLI for ColdFusion (CFML):
# install testbox box install testbox # update testbox box update testbox #what you thought there was more?
Major Features
Below you can find quick updates on our major features for this release.
Spec Data Binding
Every specification created via the it() function now receives a data argument that can be used to pass in a struct of data into the spec so it can be used later within the execution closure. This is great when doing looping and dynamic closure calls:
// Simple Example
it( title="can handle binding", body=function( data ){
expect( data.keep ).toBeTrue();
}, data = { keep = true } );
// Complex Example
for (filePath in files) {
it("#getFileFromPath(filePath)# should be valid JSON", function() {
var json = fileRead(filePath);
var isItJson = isJSON(json);
expect(json).notToBeEmpty();
expect(isItJson).toBeTrue();
if (isItJson) {
var data = deserializeJSON(json);
if (getFileFromPath(filePath) != "index.json") {
expect(data).toHaveKey("name");
expect(data).toHaveKey("type");
}
}
});
}
Given-When-Then Blocks
Given-When-Then is a style of writing tests where you describe the state of the code you want to test (Given), the behavior you want to test (When) and the expected outcome (Then). (See Specification By Example)
Testbox supports the use of function names given() and when() in-place of describe() function calls. The then() function call is an alternative for it() function calls. The advantage of this style of behavioural specifications is that you can gather your requirements and write your tests in a common language that can be understood by developers and stake-holders alike. This common language format is often referred to as the Gherkin language; using it we can gather and document the requirements as:
Feature: Box Size
In order to know what size box I need
As a distribution manager
I want to know the volume of the box
Scenario: Get box volume
Given I have entered a width of 20
And a height of 30
And a depth of 40
When I run the calculation
Then the result should be 24000
TestBox provides you with feature(), scenario() and story() wrappers for describe() blocks. As such we can write our requirements in test form like so:
feature( "Box Size", function(){
describe( "In order to know what size box I need
As a distribution manager
I want to know the volume of the box", function(){
scenario( "Get box volume", function(){
given( "I have entered a width of 20
And a height of 30
And a depth of 40", function(){
when( "I run the calculation", function(){
then( "the result should be 24000", function(){
// call the method with the arguments and test the outcome
expect( myObject.myFunction(20,30,40) ).toBe( 24000 );
});
});
});
});
});
});
The output from running the test will read as the original requirements, providing you with not only automated tests but also a living document of the requirements in a business-readable format.
Stories Syntax
If you prefer to gather requirements as User Stories then you may prefer to take advantage of the story() wrapper for describe() instead.
story("As a distribution manager, I want to know the volume of the box I need", function() {
given("I have a width of 20
And a height of 30
And a depth of 40", function() {
when("I run the calculation", function() {
then("the result should be 24000", function() {
// call the method with the arguments and test the outcome
expect(myObject.myFunction(20,30,40)).toBe(24000);
});
});
});
});
As feature(), scenario() and story() are wrappers for describe() you can intermix them so that your can create tests which read as the business requirements. As with describe(), they can be nested to build up blocks.
Run Listeners
Every run and runRaw methods now accept a callbacks argument, which can be a CFC with the right listener methods or a struct with the right closure methods. This will allow you to listen to the testing progress and get information about it. This way you can build informative reports or progress bars.
The available callbacks are:
function onBundleStart( target, testResults ) function onBundleEnd( target, testResults ) function onSuiteStart( target, testResults, suite ) function onSuiteEnd( target, testResults, suite ) function onSpecStart( target, testResults, suite, spec ) function onSpecEnd( target, testResults, suite, spec )
Add Your Comment