TestBox : Behavior Driven Development (BDD)
API DocsSourceSupportBoxLang
v4.x
v4.x
  • Introduction
  • Intro
    • Release History
      • What's New With 4.5.0
      • What's New With 4.4.0
      • What's New With 4.3.0
      • What's New With 4.2.x
      • What's New With 4.1.0
      • What's New With 4.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
      • BDD
      • xUnit
      • 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
      • 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
    • Mocking Data
  • Code Coverage
    • Introduction
    • Running Code Coverage
    • Configuring Code Coverage
    • Known Behaviors
  • Continuous Integration
    • Introduction
    • Github Actions
    • 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
  • About GitHub Actions
  • Features
  • TestBox Integration
  • Box.json
  • Online Example

Was this helpful?

Edit on GitHub
Export as PDF
  1. Continuous Integration

Github Actions

PreviousIntroductionNextGitlab

Last updated 2 years ago

Was this helpful?

About GitHub Actions

is an automation platform built in to GitHub.com that makes it easy to automate code quality on your github repos. There are a number of integrations that make using TestBox inside GitHub Actions simple, speedy and powerful so you can get back to writing code.

Features

  • FREE for public repositories

  • 2,000 minutes for private repos

  • Can reuse workflows, i.e. for a standard test.yml workflow in both builds and PR testing

  • Can schedule workflow runs

  • [Can configure a build "matrix"], i.e. for

TestBox Integration

Testing your application with TestBox in GitHub Actions (GHA) begins a workflow.yml file at the root of a .github/workflows/ directory. You can name this file anything you like - I'd suggest build.yml or test.yml - but if it is not a valid Yaml file the GHA workflow will fail.

This file should start with some GHA metadata to dictate when and how the workflow should run:

# .github/workflows/tests.yml
name: Test

on:
  push:
    branches:
      - main
      - master
      - development

This will run the workflow on each commit to the master or main branch. Next, specify a workflow job to execute:

jobs:
  tests:
    name: Tests
    runs-on: ubuntu-latest
    steps:
      - # All job steps go here

Under the jobs.tests.steps is where we will place each sequential testing step. First, we need to check out the repository code and install Java and CommandBox:

      - name: Checkout Repository
        uses: actions/checkout@v2
        with:
          fetch-depth: 0

      - name: Setup Java
        uses: actions/setup-java@v2
        with:
          distribution: "adopt"
          java-version: "11"

      - name: Setup CommandBox
        uses: Ortus-Solutions/setup-commandbox@main

If we need to install dependencies, we would do that now:

      - name: Install dependencies
        run: box install

And finally, we can start a CFML server of our choice using CommandBox, before using the testbox run command to run our test suite:

      - name: Start server
        run: box server start cfengine=lucee@5.3 --noSaveSettings

      - name: Run TestBox Tests
        run: box testbox run

The full example would look something like this:

# .github/workflows/tests.yml
name: Test

on:
  push:
    branches:
      - main
      - master
      - development
jobs:
  tests:
    name: Tests
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repository
        uses: actions/checkout@v2
        with:
          fetch-depth: 0

      - name: Setup Java
        uses: actions/setup-java@v2
        with:
          distribution: "adopt"
          java-version: "11"

      - name: Setup CommandBox
        uses: Ortus-Solutions/setup-commandbox@main

      - name: Install dependencies
        run: box install

      - name: Start server
        run: box server start cfengine=lucee@5.3 --noSaveSettings

      - name: Run TestBox Tests
        run: box testbox run

Box.json

In order for the box testbox run to execute correctly, our box.json in our project must be able to connect to our server and know which tests to execute. Here's a basic example showing the most important testbox property: the testbox.runner property:

{
    "name" : "Package Name",
    // ForgeBox unique slug
    "slug" : "",
    // semantic version of your package
    "version" : "1.0.0+buildID",
    // author of this package
    "author" : "Luis Majano <lmajano@ortussolutions.com>",
    // location of where to download the package, overrides ForgeBox location
    "location" : "URL,Git/svn endpoint,etc",

    // testbox integration
    testbox :{
        // The location of the runner
        runner : [
            { "default": "http://localhost:8080/tests/runner.cfm" }
        ]
    }
}

Online Example

If you are using a testing matrix to test against multiple CFML engines, replace lucee@5.3 with ${{ matrix.cfengine }}.

We can also Just be aware that the TestBox integration offers a ton of configuration in case you need to skip certain tests, etc. from your GitHub Actions test run.

See for more details.

is an ORM utility wrapper for ColdBox that takes the pain out of using ORM in CFML. CBORM uses GitHub Actions to test all new commits, to package up new module versions, and even to .

See , or see .

See an example here
skip setting the testbox.runner property and use the box testbox run "http://localhost:8080/tests/runner.cfm" command format instead.
the CommandBox docs for box.json
CBORM
format all CFML code for every new PR
All CBORM Workflows
recent GitHub Actions workflow runs here
GitHub Actions
testing against all recent CFML engines
Thousands of configurable, reusable "Actions"
Can notify Slack on build failure
GitHub Actions logo