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
  • Code Coverage
  • Requirements

Was this helpful?

Edit on Git
Export as PDF
  1. Code Coverage

Introduction

PreviousConclusionNextRunning Code Coverage

Last updated 6 years ago

Was this helpful?

When writing tests for an app or library, it's generally regarded that more tests is better since you're covering more functionality and more likely to catch regressions as they happen. This is true, but more specifically, it's important that your tests run as much code in your project as possible. Tests obviously can't check code that they doesn't run!

With BDD, there is not a one-to-one correlation between a test and a unit of code. You may have a test for your login page, but how do you know if all the else blocks in your if statements or case blocks in your switch statements were run? Was your error routine tested? What about optional features, or code that only kicks in on the 3rd Tuesday of months in the springtime? These can be difficult questions to answer just by staring at the results of your tests. The answer to this is Code Coverage.

Code Coverage

Code coverage does not replace your tests nor does it change how you write your tests. It's additional metrics gathered by the testing framework while your tests are running that actually tracks what lines of code were executed and what lines of code didn't get run. Now you can finally see how much code in your app is "covered" by your tests and what code is currently being untested.

TestBox supports code coverage statistics out-of-the box with no changes to your test suite and you can capture the data in a handful of ways, including a Coverage Browser report which visualizes every CF file in your code and shows you what lines executed and what lines didn't.

Requirements

  • TestBox 3.x+

7+ (separate license required)

Please note that FusionReactor is a separate product not made by Ortus, but by Intergral GmbH. FusionReactor is a performance monitoring tool for Java-based servers and you will need to purchase a license to use it. We understand you may wish to use code coverage for free, but this feature would not have been possible without the line performance tracking feature of FusionReactor that allows us to match your Java bytecode to the actual code lines of your CFML. For personal use, there is a reasonably-priced . Please reach out to if you have any questions.

FusionReactor
Developer Edition
FusionReactor's sales team