Creating a synthetic API test monitor on a budget with Github Actions

2020-09-30 Github Actions Test Synthetic Test Jest

Creating a synthetic API test monitor on a budget with Github Actions

One of the newer CI runner can help create wonders on a shoe string budget

In this article, I will go through how we have created our first rudimental — yet effective — synthetic test worker on no money. This leverages Github Action, Github Issues and a Jest Reporter.

Alerting on Github Issue with a custom Jest Reporter

Sometimes, you want a simple way to do alerting without the frills, and on the cheap. Using Jest reporters is often time used to generate artefacts like HTML reports, but you can also utilise it for logging and applications such as gathering test results to pass them onto another entity. This simple reporter raises alerts to Github Issues when Jest Tests fails and has given me satisfying results.

const Octokit = require('@octokit/rest').Octokit
const { env: { GH_SYNTH_TOKEN, ISSUE_TITLE } } = process
const octokit = new Octokit({ auth: GH_SYNTH_TOKEN })
const labels = ['api', 'critical']

class GHIssueReporter {
  constructor(globalConfig, options) {
    this._globalConfig = globalConfig
    this._options = options
    if (!GH_SYNTH_TOKEN) {
      throw new Error('A GitHub token with full repo permission must be available as the environment variable "GH_SYNTH_TOKEN"')
    }
  }

  formatMarkdown(errors) {
    return `
Unexpected interactions with API endpoint caught during synthetic testing.\n
The following tests have failed:\n
${errors.map(({ title }) => `\t🚫 ${title}\n`).join('')}\n
Please fix the API or the tests ASAP
`
  }

  async onRunComplete(contexts, results) {=
    let failedTests = []

    for (const apiTestResults of results.testResults) {
      const currentFailedTests = apiTestResults.testResults.filter(({ status }) => status === 'failed')
      failedTests = [...failedTests, ...currentFailedTests]
    }

    if (!failedTests.length) {
      console.log('\nAnother day, another dollar 👍')
      return
    }

    const body = this.formatMarkdown(failedTests)

    try {
      const { data } = await octokit.issues
        .create({
          owner: 'github-name-of-owner',
          repo: 'repo-name',
          title: ISSUE_TITLE,
          labels,
          body,
          assignees: ['your-github-name']
        })

      console.error(`Issue raised on Github (${data.html_url})`)

    } catch (e) {
      console.error(`Github error : ${JSON.stringify(e)}`)
    }
  }
}

module.exports = GHIssueReporter

Save it under jest-reporter-github-issues.js.

Set up

Add the following to your package.json file, add your tests in your preferred directory, et voilà!

{
  "jest": {
    "reporters": [
      "./jest-reporter-github-issues.js"
    ]
  }
}

If a machine runs your tests, you can use the following options.

{
  "scripts": {
    "test": "jest --ci --passWithNoTests --noStackTrace"
  }
}

(NB: the outer curly brace should already be in your file)

Creating a scheduled runner with Github Actions

Coming from a CircleCI environment, we have made (what seemed like) the bold decision to use Github Actions as a central part of our CI/CD process. Passed the initial pain of having to navigate the somewhat lacking documentation, the possibilities of the tool have started to become more apparent. A huge part of alleviating some of that pain was the excellent Act tool, a Docker-based wrapper around the Github Actions runner to help running some of the jobs locally and immediately. This became particularly useful to: 1. Avoid polluting our history with a brutally high amount of commits 2. Running through all of our free credits 3. Avoid having to wait for rare conditions such as those that the jobs relying on a timer such (example) One less known feature on Github Actions is the presence of a scheduler functionality. Here is an example to store in a yml/yaml file under .github/workflows.

name: Integration Tests On Endpoints
on:
  schedule:
    - cron: 0 0 * * *

jobs:
  integration-tests:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v1

      - name: "Run integration tests"
        run: npm ci && npm run test
        env:
            ISSUE_TITLE: "Synthetic Tests: Unexpected response from API"

For best results

For maximum results, you should be notified of new issues via email. Try the account notifications page, specifically the section under ‘Issues’ and make sure that you are receiving the notifications via email. We hope you have enjoyed this article. As always, your feedback and suggestions are welcome. Story originally published on agreeme

Recent Posts