TestBox : Behavior Driven Development (BDD)
API DocsSourceSupportBoxLang
v6.x
v6.x
  • Introduction
    • Release History
      • What's New With 6.3.0
      • What's New With 6.2.1
      • What's New With 6.2.0
      • What's New With 6.1.0
      • What's New With 6.0.1
      • What's New With 6.0.0
    • About This Book
      • Author
  • Getting Started
    • Overview
    • Installation
      • IDE Tools
      • MXUnit Compatibility
    • Writing Tests
    • Running Tests
      • BoxLang CLI Runner
      • CommandBox Runner
      • Web Runner
      • Bundle(s) Runner
      • Directory Runner
      • ANT Runner
      • NodeJS Runner
      • Global Runner
      • Test Browser
    • BDD Tests
      • Bundles: Group Your Tests
      • Suites: Describe Your Tests
        • Dynamic Suites
      • Specs
      • Expectations
      • Suite Groups
        • Given-When-Then Blocks
      • Life-Cycle Methods
      • Life-Cycle Data Binding
      • Specs and Suite Labels
      • Skipping Specs and Suites
      • Focused Specs and Suites
      • Spies & Mocking
      • Asynchronous Testing
      • Running Tests
      • Reporters
    • xUnit Tests
      • Test Bundles
      • Life-Cycle Methods
      • Test Methods
      • Assertions
      • Test and Suite Labels
      • Skipping Tests and Suites
      • Spies and Mocking
      • Asynchronous-Testing
      • Running Tests
      • Reporters
  • Digging Deeper
    • Life-Cycle Annotations
    • Assertions
      • Custom Assertions
    • Expectations
      • Matchers
      • Not Operator
      • Expecting Exceptions
      • Custom Matchers
    • Output Utilities
    • Runner Listeners
    • Reporters
      • Custom Reporters
    • Modules
    • Code Coverage
      • Running Code Coverage
      • Configuring Code Coverage
      • Known Behaviors
    • Continous Integration
      • Github Actions
      • Gitlab
      • Travis
  • Mocking
    • MockBox
      • What is Mocking?
      • Our Approach and Benefits
      • Creating MockBox
      • Creating a Mock Object
      • Creating a Stub Object
      • Mocking Methods
        • $() Method
        • $args() Method
        • $getProperty() Method
        • $property() Method
        • $querySim() Method
        • $results() Method
        • $spy()
        • $throws() Method
      • Verification Methods
        • $count()
        • $times() or $verifyCallCount()
        • $never()
        • $atLeast()
        • $once()
        • $atMost()
        • $callLog()
        • $reset()
        • $debug()
      • Some Examples
      • Conclusion
    • Mocking Data
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

Was this helpful?

Edit on GitHub
Export as PDF
  1. Digging Deeper

Runner Listeners

If you are creating runners and want to tap into the runner listeners or callbacks, you can do so by creating a class or a struct with the different events we announce.

Event
Description

onBundleStart

When each bundle begins execution

onBundleEnd

When each bundle ends execution

onSuiteStart

Before a suite (describe, story, scenario, etc)

onSuiteEnd

After a suite

onSpecStart

Before a spec (it, test, then)

onSpecEnd

After a spec

Every run and runRaw methods accepts a callbacks argument, which can be a Class 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.

class{

    // Called at the beginning of a test bundle cycle
    function onBundleStart( target, testResults ){
    
    }
    
    // Called at the end of the bundle testing cycle
    function onBundleEnd( target, testResults ){
    
    }
    
    // Called anytime a new suite is about to be tested
    function onSuiteStart( target, testResults, suite ){
    
    }
    
    // Called after any suite has finalized testing
    function onSuiteEnd( target, testResults, suite ){
    
    }
    
    // Called anytime a new spec is about to be tested
    function onSpecStart( target, testResults, suite, spec ){
    
    }
    
    // Called after any spec has finalized testing
    function onSpecEnd( target, testResults, suite, spec ){
    
    }
    
}
PreviousOutput UtilitiesNextReporters

Was this helpful?