In this section you will find the release notes for each version we release under this major version. If you are looking for the release notes of previous major versions use the version switcher at the top left of this documentation book. Here is a breakdown of our major version releases.

Version 3.0

In this release we focused on dropping engine supports for legacy CFML engines. We had a major breakthrough in introducing Code Coverage thanks to the FusionReactor folks as well. This major release came also with a new UI for all reporters and streamlining the result view ports.

Version 2.0

This version spawned off with over 8 minor releases. We focused on taking TestBox 1 to yet a high level. Much more attention to detail and introducing modern paradigms like given-when-then. Multiple interception points, async executions and ability to chain methods.

Version 1.0

This was our first major version for TestBox. We had completely migrated from MXUnit and it introduced BDD to the ColdFusion (CFML) world.

Major Features

Focused Suites and Specs

This was asked for a long time ago and finally we can oblige. You can now prefix any of the suite and spec methods with the letter f and they will be focused. Meaning, ONLY those suites or specs will be executed.

• fit(), fthen() - Spec Methods

• fdescribe(), fscenario(), fstory(), ffeature(), fgiven(), fwhen() - Suite Methods

This is great if you ONLY want certain things to execute instead of the x prefix which was used to EXCLUDE specs and suites.

function run( testResults, testBox ){
	// all your suites go here.
	describe( "My First Suite", function(){

		it( "A Spec that should not run", function(){
			fail( 'implement' );
		});

		it( "A Spec that should not run", function(){
			fail( 'implement' );
		});

		fit( "This should execute", function(){
			expect( 1 ).toBeTrue();
		});

		it( "A Spec that should not run", function(){
			fail( 'implement' );
		});

		fit( "This should execute as well", function(){
			expect( 1 ).toBeTrue();
		});

		fdescribe( "All specs here should run", function(){

			it( "should run", function(){

			});
			it( "should run", function(){

			});
			it( "should run", function(){

			});
		} );

		describe( "All specs here should NOT run", function(){

			it( "A Spec that should not run", function(){
				fail( 'implement' );
			});

			it( "A Spec that should not run", function(){
				fail( 'implement' );
			});

			it( "A Spec that should not run", function(){
				fail( 'implement' );
			});

		} );

	});

	fdescribe( "My Focused Suite", function(){

		it( "This should execute", function(){
			expect( 1 ).toBeTrue();
		});

		describe( "All specs here should run", function(){

			it( "should run", function(){

			});
			it( "should run", function(){

			});
			it( "should run", function(){

			});
		} );

		xdescribe( "skipped suites", function(){

			it( "A Spec that should not run", function(){
				fail( 'implement' );
			});

			it( "A Spec that should not run", function(){
				fail( 'implement' );
			});

			it( "A Spec that should not run", function(){
				fail( 'implement' );
			});

		} );

	});

Here are the results:

toHaveKey() can now work with key lists

How many times did you want to check if a struct had ALL the keys or NO keys at all. Well, now you can. You can pass a list of keys into the toHaveKey() expectation and we will make sure your structure has ALL the keys in it.

var s = {
	"data" : {},
	"error" : {},
	"name" : {},
	"age" : 0
};

expect( s ).toHaveKey( "error" );
expect( s ).notToHaveKey( "luis" );

// Multiple
expect( s ).toHaveKey( "data,error,name,age" );
expect( function(){
	expect( s ).toHaveKey( "data,error,name,age2" );
}).toThrow();
expect( s ).notToHaveKey( "luis,joe,tom" );
expect( function(){
	expect( s ).toHaveKey( "luis,joe,data" );
}).toThrow();

fail() Improvements

You can now pass in a detail to the fail messages that can be used to track exception details, stacktraces, extended info and much more. Sometimes, this can be a life-saver when dealing with toThrow() expectations:

/**
 * Fail an assertion
 *
 * @message The message to fail with.
 * @detail The detail to fail with.
 */
function fail( message = "", detail = "" ){
	variables.assert.fail( argumentCollection = arguments );
}

Which is exactly what we did. The catching of expected exceptions now pass in the exact stacktrace where they failed instead of the nested exception. Which goes nicely into our next major improvement.

Nested Exceptions

We all hate them and not easy to track. In this release we at least try to add more debugging on the results by introducing the following new keys and output on the reporters:

• failDetail

• failExtendedInfo

• failStacktrace

CFML Engine/Version Detection

The reporters know will output the CFML engine the report is executed on. Also, the raw json/xml reporters will also report back the CFML engine and version.

Release Notes

Bugs

• [TESTBOX-251] - Scripts don't output if runner.cfm has enableCFoutputOnly set to true

• [TESTBOX-252] - JSON,xml,Junit, Ant reporters fails for integration tests with cfhtmlhead and cfheader

• [TESTBOX-257] - Update build process to upload the right version assets

New Features

• [TESTBOX-255] - Added new spec stats to track nested exceptions: failDetail, failExtendedInfo, failStacktrace

• [TESTBOX-256] - Add a detail argument to the fail() method to allow for more in-depth tracking of failures, especially when using the `toThrow()` expectation

• [TESTBOX-258] - Added CFMLEngine and CFMLEngineVersion to results memento so any consumer can display this information

• [TESTBOX-253] - Display the CFML engine in use when using the simple reporter

• [TESTBOX-198] - Add support to fit, fdescribe, fscenario,fwhen, fgiven, fstory, ffeature, fthen

Improvements

• [TESTBOX-254] - check if fail origin is an array in case internal TestBox borks out in all the reporters

• [TESTBOX-259] - Turn off code coverage when clicking a link in the HTML reporter

• [TESTBOX-260] - toHaveKey() now accepts a list of keys that MUST or MUST NOT exist in the collection

Bugs

• [TESTBOX-265] - Code coverage doesn't always capture ending parenthesis

• [TESTBOX-268] - When the key existed notToHaveKey wasn't failing

• [TESTBOX-269] - missing raw_trace in simple.cfm

• [TESTBOX-270] - Lowercase cbstreams for case-sensitive file systems

Improvements

• [TESTBOX-267] - Moved invoke block from bottom of method into if block for "detect negation" instead of stack overflow errors

• [TESTBOX-272] - Add formatting config and scripts

TestBox 3.0.0 is a major release. It has compatibility changes that you should be aware and lots of good feaures!

Compatibility

The major compatibility issues are the engine support removals:

• Lucee 4.5 Support Dropped

• Adobe ColdFusion 10 Dropped

Updating

It is easy to update, just type update testbox and you are done!

Major Features

The most notable features of this release can be found below.

Code Coverage

This has been fully documented and you can find much more information in the code coverage section.

Static Test Visualizer

The static test visualizer is basically the simple reporter but works in offline mode. This means that it will read a static TestBox results json file and create the report for it in the browser. This is incredibly useful for CI integrations and representing any TestBox results json file visually.

Location

You will find the analyzer under /test-visualizer in the root of the TestBox installation.

/test-analyzer
  + index.html (visualizer)
  + test-results.json (sample test results)

Running It

To run it all you need to do is put alongside of it a test-results.json file and then run the index.html and voila! Test Results Visualized!

Release Notes

Bugs

• [TESTBOX-234] - bddrunner.cfm: now compiles properly on ACF

• [TESTBOX-248] - Skip methods for given/when/then fail without `this` reference

New Features

• [TESTBOX-236] - Add CodeCoverage Reporter to TestBox

• [TESTBOX-239] - Update the UI for the code coverage reporting and code visualizer

• [TESTBOX-243] - Complete UI updates for test reporters

• [TESTBOX-245] - Static Test Visualizer

Improvements

• [TESTBOX-237] - Update usage of htmleditformat to encodeForHTML

• [TESTBOX-242] - Removal of old cfml engines support acf10 and lucee 4.5

• [TESTBOX-244] - streamify the code coverage collection

• [TESTBOX-249] - Add original method name to mocking function so it can help in debugging