TestBox : Behavior Driven Development (BDD)
API DocsSourceSupportBoxLang
v3.x
v3.x
  • Introduction
  • Intro
    • Release History
      • What's New With 3.2.0
      • What's New With 3.1.0
      • What's New With 3.0.0
    • About This Book
      • Author
  • Getting Started
    • Overview
    • Installation
      • IDE Tools
  • Primers
    • TestBox BDD Primer
      • Bundles: Group Your Tests
      • Suites: Describe Your Tests
        • Dynamic Suites
      • Specs
      • Expectations
      • Suite Groups
        • Given-When-Then Blocks
      • Life-Cycle Methods
      • Specs and Suite Labels
      • Skipping Specs and Suites
      • Focused Specs and Suites
      • Spies & Mocking
      • Asynchronous Testing
      • Running Tests
      • Reporters
    • TestBox xUnit Primer
      • RefCard
      • Requirements
      • Bundles: Group Your Tests
      • Test Methods
      • Assertions
      • Setup and Teardown
      • Test and Suite Labels
      • Skipping Tests and Suites
      • Spies and Mocking
      • Asynchronous-Testing
      • Running Tests
      • Reporters
  • In-Depth
    • Testing Styles
    • Test Bundles
      • Optional Inheritance
      • Injected Variables
      • Injected Methods
    • Life-Cycle Methods
      • xUnit
      • BDD
      • Annotations
    • Suites, Tests & Specs (Oh My!)
      • xUnit
      • BDD
    • Assertions
      • Custom Assertions
    • Expectations
      • Matchers
      • Not Operator
      • Expecting Exceptions
      • Custom Matchers
    • Output Utilities
    • Running Tests
      • Run Listeners
      • Global Runner
      • Test Browser
      • Bundle(s) Runner
      • Test Runner
      • Directory Runner
      • SOAP Runner
      • HTTP REST Runner
      • ANT Runner
      • NodeJS Runner
    • Reporters
      • Custom Reporters
    • MXUnit Compatibility
  • Mocking
    • MockBox
      • System Requirements
      • Installing Mockbox
      • What is Mocking?
      • Our Approach and Benefits
      • Creating MockBox
      • Creating a Mock Object
      • Creating a Stub Object
      • Mocking Methods
        • $() Method
        • $property() Method
        • $getProperty() Method
        • $results() Method
        • $args() Method
        • $throws() Method
        • $querySim() Method
      • Verification Methods
        • $count()
        • $times() or $verifyCallCount()
        • $never()
        • $atLeast()
        • $once()
        • $atMost()
        • $callLog()
        • $reset()
        • $debug()
      • Some Examples
      • Conclusion
  • Code Coverage
    • Introduction
    • Running Code Coverage
    • Configuring Code Coverage
    • Known Behaviors
  • Continuous Integration
    • Introduction
    • Gitlab
    • Travis
Powered by GitBook

Social Media

  • YouTube
  • x
  • FaceBook
  • LinkedIn

Downloads

  • CommandBox
  • BoxLang
  • Try BoxLang

Support

  • Professional
  • Community
  • Slack
  • CFCasts

Copyright & Register Trademark by Ortus Solutions, Corp & Ortus Software, LLC

On this page
  • Matcher Registration
  • Inline matchers
  • CFC Matchers

Was this helpful?

Edit on Git
Export as PDF
  1. In-Depth
  2. Expectations

Custom Matchers

TestBox comes with a decent amount of matchers that cover what we believe are common scenarios. However, we recommend that you create custom matchers that meet your needs and criteria so that you can avoid duplication and have re-usability.

Every custom matcher is a function and must have the following signature, with MyMatcher being the name of your custom matcher function:

boolean function MyMatcher( required expectation, args={} )

The matcher function receives the expectation object and a second argument which is a structure of all the arguments with which the matcher function was called with. It must then return a true or a false depending if it passes your criteria. It will most likely use the expectation object to retrieve the actual and isNot values. It can also set a custom failure message on the expectation object itself by using the message property of the expectation object.

boolean function reallyFalse( expectation, args={} ){
     expectation.message = ( structKeyExists( args, "message" ) ? args.message : "[#expectation.actual#] is not really false" );
     if( expectation.isNot )
          return ( expectation.actual eq true );
     else
          return ( expectation.actual eq false );
     }
}

The next step is to tell TestBox about your matcher.

Matcher Registration

You can register matcher functions in several ways within TestBox, but we always recommend that you register them inside of the beforeAll() or beforeEach() life-cycle method blocks for performance considerations and global availability.

Inline matchers

You can pass a structure of key\/value pairs of the matchers you would like to register. The key is the name of the matcher function and the value is the closure function representation.

function beforeAll(){

  addMatchers( {
       toBeAwesome : function( expectation, args={} ){ return expectation.actual gte 100; },
       toBeGreat : function( expectation, args={} ){ return expectation.actual gte 1000; },
       // please note I use positional values here, you can also use name-value arguements.
       toBeGreaterThan : function( expectation, args={} ){ return ( expectation.actual gt args[ 1 ]  ); }
  } );

}

After it is registered, then you can use it.

it("A custom matcher", function(){
  expect( 100 ).toBeAwesome();
  expect( 5000 ).toBeGreat();
  expect( 10 ).toBeGreaterThan( 5 );
});

CFC Matchers

addMatchers( "model.util.MyMatchers" );

You can also register a CFC instance:

addMatchers( new models.util.MyMatchers() );
PreviousExpecting ExceptionsNextOutput Utilities

Last updated 7 years ago

Was this helpful?

You can also store a of matchers (Yes, I said plethora), in a CFC and register that as the matchers via its instantiation path. This provides much more flexibility and re-usability for your projects.

plethora