Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
The testing bundle CFC is actually the suite in xUnit style as it contains all the test methods you would like to test with. Usually, this CFC represents a test case for a specific software under test (SUT), whether that's a model object, service, etc. This component can have some cool annotations as well that can alter its behavior.
TestBox relies on the fact of creating testing bundles which are basically CFCs. A bundle CFC will hold all the tests the TestBox runner will execute and produce reports on. Thus, sometimes this test bundle is referred to as a test suite in xUnit terms.
Caution If you activate the
asyncAll
flag for asynchronous testing, you HAVE to make sure your tests are also thread safe and appropriately locked.
Unit testing is a software testing technique where individual components of a software application, known as units, are tested in isolation to ensure they work as intended. Each unit is a small application part, such as a function or method, and is tested independently from other parts. This helps identify and fix bugs early in the development process, ensures code quality, and facilitates easier maintenance and refactoring. Tools like TestBox allow developers to create and run automated unit tests, providing assertions to verify the correctness of the code.
TestBox supports xUnit style of testing, like in other languages, via the creation of classes and functions that denote the tests to execute. You can then evaluate the test either using or the library included with TestBox.
You will start by creating a test bundle (Usually with the word Test
in the front or back), example: UserServiceTest
or TestUserService
.
TestBox not only provides you with global life-cycle methods but also with localized test methods. This is a great way to keep your tests DRY (Do not repeat yourself)!
beforeTests()
- Executes once before all tests for the entire test bundle CFC
afterTests()
- Executes once after all tests complete in the test bundle CFC
setup( currentMethod )
- Executes before every single test case and receives the name of the actual testing method
teardown( currentMethod )
- Executes after every single test case and receives the name of the actual testing method
Examples
You can tag a bundle component declaration with the boolean asyncAll
annotation and TestBox will execute all specs in separate threads for you concurrently.
Caution Once you delve into the asynchronous world you will have to make sure your tests are also thread safe (var-scoped) and provide any necessary locking.
Argument
Required
Default
Type
Description
displayName
false
--
string
If used, this will be the name of the test suite in the reporters.
asyncAll
false
false
boolean
If true, it will execute all the test methods in parallel and join at the end asynchronously.
labels
false
---
string/list
The list of labels this test belongs to
skip
false
false
boolean/udf
A boolean flag that makes the runners skip the test for execution. It can also be the name of a UDF in the same CFC that will be executed and MUST return a boolean value.
Tests and suites can be skipped from execution by using the skip
annotation in the component or function declaration or our skip()
methods. The reporters will show that these suites or tests where skipped from execution.
The skip
annotation can have the following values:
nothing
- If you just add the annotation, we will detect it and skip the test
true
- Skips the test
false
- Does not skip the test
{udf_name}
- It will look for a UDF with that name, execute it and the value must evalute to boolean.
You can also skip manually by using the skip()
method in the Assertion
library and also in any bundle which is inherited by the BaseSpec
class.
You can use the $assert.skip( message, detail )
method to skip any spec or suite a-la-carte instead of as an argument to the function definitions. This lets you programmatically skip certain specs and suites and pass a nice message.
The BaseSpec
has this method available to you as well.
TestBox comes also with a nice plethora of reporters:
ANTJunit : A specific variant of JUnit XML that works with the ANT junitreport task
Codexwiki : Produces MediaWiki syntax for usage in Codex Wiki
Console : Sends report to console
Doc : Builds semantic HTML to produce nice documentation
Dot : Builds an awesome dot report
JSON : Builds a report into JSON
JUnit : Builds a JUnit compliant report
Raw : Returns the raw structure representation of the testing results
Simple : A basic HTML reporter
Text : Back to the 80's with an awesome text report
XML : Builds yet another XML testing report
Tap : A test anything protocol reporter
Min : A minimalistic view of your test reports
MinText : A minimalistic view of your test reports for consoles
NodeJS : User-contributed: https://www.npmjs.com/package/testbox-runner
Please refer to our MockBox section to take advantage of all the mocking and stubbing you can do. However, every BDD TestBundle has the following functions available to you for mocking and stubbing purposes:
makePublic( target, method, newName )
- Exposes private methods from objects as public methods
querySim( queryData )
- Simulate a query
getMockBox( [generationPath] )
- Get a reference to MockBox
createEmptyMock( [className], [object], [callLogging=true])
- Create an empty mock from a class or object
createMock( [className], [object], [clearMethods=false], [callLogging=true])
- Create a spy from an instance or class with call logging
prepareMock( object, [callLogging=true])
- Prepare an instance of an object for method spies with call logging
createStub( [callLogging=true], [extends], [implements])
- Create stub objects with call logging and optional inheritance trees and implementation methods
getProperty( target, name, [scope=variables], [defaultValue] )
- Get a property from an object in any scope
Tests and suites can be tagged with TestBox labels. Labels allows you to further categorize different tests or suites so that when a runner executes with labels attached, only those tests and suites will be executed, the rest will be skipped. Labels can be applied globally to the component declaration of the test bundle suite or granularly at the test method declaration.
TestBox discovers test methods in your bundle CFC by applying the following discovery rules:
Any method that has a test annotation on it
Any public method that starts or ends with the word test
Each test method will test the state of the SUT (software under test) or sometimes referred to as code under test. It will do so by asserting that actual values from an execution match an expected value or condition. TestBox offers an assertion library that you have available in your bundle via the injected variable $assert. You can also use our expectations library if you so desire, but that is mostly used in our BDD approach.
Each test function can also have some cool annotations attached to it.
Running tests is essential of course. There are many ways to run your tests, we will see the basics here, and you can check out our Running Tests section in our in-depth guide.
The easiest way to run your tests is to use the TestBox CLI via the testbox run
command. Ensure you are in the web root of your project or have configured the box.json
to include the TestBox runner in it as shown below. If not CommandBox will try to run by convention your site + test/runner.cfm
for you.
You can also pass the runner URL via the testbox run
command. Try out the testbox run help
command.
Here is a simple box.json
config that has a runner and some watcher config.
Check out the watcher command: testbox watch
Every test harness also has an HTML runner you can execute. By convention the URL is
This will execute ALL tests in the tests/specs
directory for you.
You can also target a specific spec to execute via the URL
TestBox ships with a global runner that can run pretty much anything. You can customize it or place it wherever you need it:
TestBox ships with a test browser that is highly configurable to whatever URL-accessible path you want. It will then show you a test browser where you can navigate and execute not only individual tests but also directory suites.
Argument
Required
Default
Type
Description
labels
false
---
string/list
The list of labels this test belongs to
skip
false
false
boolean/udf
A boolean flag that makes the runners skip the test for execution. It can also be the name of a UDF in the same CFC that will be executed and MUST return a boolean value.
Assertions are self-concatenated strings that evaluate an actual value to an expected value or condition. These are initiated by the global TestBox variable called $assert which contains tons of included assertion methods so you can evaluate your tests.
Each assertion evaluator will compare the actual value and an expected value or condition. It is responsible for either passing or failing this evaluation and reporting it to TestBox. Each evaluator also has a negative counterpart assertion by just prefixing the call to the method with a not expression.
TestBox has a plethora (That's Right! I said Plethora) of evaluators that are included in the release. The best way to see all the latest evaluator methods is to visit our API and digest the coldbox.system.Assertion class. There is also the ability to register and write custom assertion evaluators in TestBox via our addAssertions() function.
You can also register custom assertions within the $assert object. You will do this by reading our Custom Assertions section of our TestBox docs.