Programmatic API for running cucumber-js

[davidjgoss]

Problem

Currently we don't have a good way to programmatically run cucumber-js. The need is from several angles:

• Testing cucumber-js - for the CCK and our acceptance tests in the project
• Testing custom formatters and snippets
• Projects that use cucumber-js as part of a framework (e.g. Serenity, Stryker)
• Projects that want to run cucumber-js programmatically for niche reasons

As-is

What tends to happen at the moment is a new instance of Cli is created with strung-together argv input. It's obviously very unweildy and also isn't on the public API.

Sometimes (possibly due to perceived fragility of the above) frameworks will just rely on the cucumber-js CLI but struggle to find ways to integrate and have their own options.

The Runtime class is currently part of the public API but it's not useful in these contexts, depending on the pickles and support code to be provided by the caller.

Proposal

Two components in the project:

runCucumber

New async function that executes a test run in-process. Responsibilities:

• Accept an options object with a nice interface
• Do the "work" of resolving pickles, loading support code, running test cases, orchestrating formatters
• Return a promise that resolves to a result

This would be part of the public API and we'd encourage framework maintainers to use it when "wrapping" cucumber-js. We'd also use it for our own testing.

As much as possible, it would avoid direct interaction with process, instead accepting normalised options and stream interfaces for output, and leaving it to the caller to decide how to exit based on the result or an unhandled error.

Also Runtime should come off the public API as it's really an internal thing.

CLI

Effectively a "client" of runCucumber. Responsibilities:

• Aggregate options from various sources (argv, env vars, config files) (see comment)
• Call runCucumber with the resolved options
• Exit as appropriate based on the results

This would continue to not be on the public API. Also it would only use functions/interfaces that are on the public API, such that we could easily break it out into its own package at some point, as is a common pattern now with projects like Jest.

This decoupling also paves the way for some interesting new CLI features without having them bleed into the internals, e.g.:

• --gui for the cucumber-electron stuff
• --interactive for quick targeted reruns when TDD'ing

etc

We would also expose functions (consumable by the CLI and by others) for:

• Getting the options
• Handling i18nKeywords and i18nLanguages

Timescale

We'd target this at the upcoming 8.0.0 release.

[davidjgoss]

Paging for initial feedback: @aslakhellesoy @charlierudolph @aurelien-reeves @mattwynne @nicojs @jan-molak

[aslakhellesoy]

I love this proposal! We already an API like this in fake-cucumber's runCucumber

[jan-molak]

@davidjgoss - sounds great!

For your reference, here's how Serenity/JS invokes Cucumber at the moment - CucumberCLIAdapter
And here's the logic around converting configuration parameters to argv - CucumberOptions.

Being able to provide an options object instead of argv would be much nicer 👍🏻

[aurelien-reeves]

Love it!

[aurelien-reeves]

While specifying that new public API, we may also consider what recently happened with issue #1489 and think about providing public APIs to have more and better interaction with the filters and the resulting features under test

[aslakhellesoy]

And to add to that - let's make something that would make it easier for Cucumber-Electron too:

• https://github.com/cucumber/cucumber-electron/blob/1c2faaa77065754d1ca17dce27fff1c421d226d0/src/renderer/main.js#L49
• https://github.com/cucumber/cucumber-electron/blob/0617ab15545ac5ceb4587599e589fefd0b670142/src/renderer/index.js#L41-L50

[nicojs]

Having a public API is better than nothing, so go ahead 👍!

Preferably I would also have an API to load profiles using the same rules as cucumber-js does, so I can mimic the exact behavior of a normal cucumber-js call.

loadProfiles(directory = process.cwd()): Record<string, Profile>

StrykerJS will also rely heavily on the custom_formatters API and the events published by the eventBroadcaster. Could we add those to the public API as well? See: https://github.com/stryker-mutator/stryker-js/blob/03b1f20ed933d3a50b52022cfe363c606c2b16c5/packages/cucumber-runner/src/stryker-formatter.ts#L45-L69

[davidjgoss]

Preferably I would also have an API to load profiles using the same rules as cucumber-js does, so I can mimic the exact behavior of a normal cucumber-js call.

This is a good point. Profiles (in their current form at least) are fundamentally coupled to the CLI so it feels right to keep them on that side of the boundary, but we could still expose a function to load them and generate a partial options object.

[davidjgoss]

While specifying that new public API, we may also consider what recently happened with issue #1489 and think about providing public APIs to have more and better interaction with the filters and the resulting features under test.

I think we could include an option for providing a custom pickle filter when calling the API (in addition to the names, tags etc that drive the built-in filtering).

[aslakhellesoy]

The current syntax for profiles if very command-line-y.

I would ❤️❤️❤️ to be able to specify profiles in a more generic format such as JSON, JavaScript, YAML or environment variables. In JSON it could look like this:

.cucumber.json

{
  "default": {
    "requireModule": ["ts-node/register"],
    "require": ["support/**/*./ts"],
    "worldParameters": {
      "appUrl": "http://localhost:3000/",
    },
    "format": ["progress-bar", "html:./cucumber-report.html"]
  },
  "ci": {
    "requireModule": ["ts-node/register"],
    "require": ["support/**/*./ts"],
    "worldParameters": {
      "appUrl": "http://localhost:3000/",
    },
    "format": ["html:./cucumber-report.html"],
    "publish": true
  }
}

Or, using JavaScript

.cucumber.js

const common = {
  "requireModule": ["ts-node/register"],
  "require": ["support/**/*./ts"],
  "worldParameters": {
    "appUrl": "http://localhost:3000/",
  }
}

module.exports = {
  default: {
    ...common,
    "format": ["progress-bar", "html:./cucumber-report.html"]
  },
  ci: {
    ...common,
    "format": ["html:./cucumber-report.html"],
    "publish": true
  }
}

Or even with environment variables (for example loaded with a tool like dotenv):

.cucumber.env

CUCUMBER_PROFILE_DEFAULT_REQUIREMODULE=ts-node/register
CUCUMBER_PROFILE_DEFAULT_REQUIRE=ts-node/register
CUCUMBER_PROFILE_DEFAULT_WORLDPARAMETERS_APPURL=http://localhost:3000/
CUCUMBER_PROFILE_DEFAULT_FORMAT=progress-bar,html:./cucumber-report.html
CUCUMBER_PROFILE_CI_REQUIREMODULE=ts-node/register
CUCUMBER_PROFILE_CI_REQUIRE=ts-node/register
CUCUMBER_PROFILE_CI_WORLDPARAMETERS_APPURL=http://localhost:3000/
CUCUMBER_PROFILE_CI_FORMAT=progress-bar,html:./cucumber-report.html
CUCUMBER_PROFILE_CI_PUBLISH=true

In fact, the config library does exactly this. We never ended up integrating it in Cucumber-JVM because other stuff got in the way, but maybe we could give it a go with a JavaScript implementation?

[davidjgoss]

@aslakhellesoy agree that would be awesome! I'll try and get a POC going for this proposal so we have something a bit more concrete to talk around, and would love to make profiles right as part of it (4.5 years and counting on #751 😄)

[aurelien-reeves]

Refs. #1004

[nicojs]

This is a good point. Profiles (in their current form at least) are fundamentally coupled to the CLI so it feels right to keep them on that side of the boundary, but we could still expose a function to load them and generate a partial options object.

Yes, that would be awesome and much appreciated from the point of view of plugin creators.

I would ❤️❤️❤️ to be able to specify profiles in a more generic format such as JSON, JavaScript, YAML or environment variables. In JSON it could look like this:

That sounds great! And is also exactly the reason I would appreciate an API to load them the same way as cucumberJS does. Loading a single cucumber.js file is trivial. Replicating a configuration file loading algorithm, including precedence, file format, etc AND maintaining it is something else entirely 😅.

[nicojs]

Q: Would I be able to run runCucumber twice in succession without clearing the require cache? This is important for the mutation testing use case.

We want to load the environment and run the tests multiple times in quick succession while changing a global variable in order to switch the active mutant.

Right now, we're using the cli private API and we need to clear the step definition files from the require.cache between each test run. This is not ideal for CommonJS and won't work at all for esm.

Pseudo code of our use case:

const profiles = await loadProfiles();
const options = {
  ...profiles.default,
  formatter: require.resolve('./our-awesomely-crafted-formatter'),
  some: 'other options we want to override',
}
const cucumber = new Cucumber(options);

// Allow cucumber to load the step definitions once. 
// This is `async`, so support for esm can be added without a breaking change
await cucumber.initialize();

// Initial test run ("dry run"), without mutants active
await cucumber.run();

collectMutantCoveragePerTestFromFormatter();

// Start mutation testing:

global.activeMutant = 1;
await cucumber.run({ features: ['features/a.feature:24']);
collectResultsFromFormatterToDetermineKilledOrSurvivedMutant()

global.activeMutant = 2;
await cucumber.run({ features: ['features/b.feature:24:25:26', 'features/c.feature:12']);
collectResultsFromFormatterToDetermineKilledOrSurvivedMutant()

// etc

[davidjgoss]

@nicojs definitely agree we need this, it's come up a few times before with e.g. people wanting to run cucumber in a lambda, and I'd also like to add an interactive mode which would need it too.

What I had sketched out so far was in more of a functional style but same fundamental concept I think:

const runnerOptions = {
    support: {
        require: ['features/support/**/*.js']
    }
}

// initial run returns support code library
const { support } = await runCucumber(runnerOptions)

// subsequent run reuses support code library
await runCucumber({
    ...runnerOptions,
    support
})

[garfieldnate]

I might be too late to the party to give input, but the API still seems fairly similar to running cucumber from the CLI, and I'm having some trouble understanding how to apply this for my use case.

I want to write a test file that contains all of the steps, then run those steps on one or more associated feature-files. I'm using TS, and I want to be able to compile the test and then run it repeatedly as I develop the feature file without having to re-do the transpilation step repeatedly, which slows down the development loop.

It's already been mentioned that I can use loadConfiguration({provided: {...}}) to define the config inline. I'm unsure of how to do the same for loadSupport; I need to create an ISupportCodeLibrary from the steps and world in the current file, but there's no documentation on how to construct this.

[binarymist]

Thanks @davidjgoss that was really helpful to get testPlan working.

It looks like the update from rc.2 to rc.3 may have broken our test functionaly?

Have you seen this error before:

Error [ERR_REQUIRE_ESM]: require() of ES Module /usr/src/app/src/steps/BrowserApp/app_scan_steps.js from /usr/src/app/node_modules/@cucumber/cucumber/lib/api/support.js not supported.
 Instead change the require of app_scan_steps.js in /usr/src/app/node_modules/@cucumber/cucumber/lib/api/support.js to a dynamic import() which is available in all CommonJS modules.
     at /usr/src/app/node_modules/@cucumber/cucumber/lib/api/support.js:14:32
     at Array.map (<anonymous>)
     at getSupportCodeLibrary (/usr/src/app/node_modules/@cucumber/cucumber/lib/api/support.js:14:18)
     at runCucumber (/usr/src/app/node_modules/@cucumber/cucumber/lib/api/run_cucumber.js:33:53)
     at async Cli.run (/usr/src/app/node_modules/@cucumber/cucumber/lib/cli/index.js:45:29)
     at async run (file:///usr/src/app/src/scripts/runCuc.js:75:14) {
   code: 'ERR_REQUIRE_ESM'
 }

app_scan_steps.js is here
runCuc.js is here

I've created a diff where the only difference is rc.2 vs rc.3 which has confirmed that this error doesn't exist with rc.2 and is introduced with rc.3.

Thanks.

[binarymist]

There doesn't appear to be a lib/api/support.js in the root of the cucumber repo, but I found a src/api/support.ts which appears to be new in rc.3 and it appears to be requireing our ESM, so as expected the error makes sense.

So it seems that cucumber in rc.2 supports ESM but rc.3 has regressed to only supporting CJS?

[davidjgoss]

@binarymist it’s still there but uses a specfic option for import vs require now - previously it was inferred but the heuristics were too fuzzy so we changed it to be explicit:

• esm: use specific option for import vs require for support code #1931
• https://github.com/cucumber/cucumber-js/blob/main/docs/esm.md

[davidjgoss]

(We should add better messaging for that, thanks for raising.)

[davidjgoss]

@garfieldnate just to make sure I understand, you want to:

• Load (including transpile) the support code once
• Use that support code on multiple test runs, triggered when you change a feature file

If so, I think you could implement this now. You can't create the support code library inline, but you can load it once and use it multiple times. Something like:

import {loadConfiguration, loadSupport, runCucumber} from '@cucumber/cucumber/api'

const {runConfiguration} = await loadConfiguration()
const support = await loadSupport(runConfiguration)
const merged = {...runConfiguration, support}

// do this bit as many times as you want e.g. in a loop or callback
await runCucumber(merged)

[davidjgoss]

Just dropping back in here to note that we'll soon be putting out a minor release with these deprecations:

• Cli
• PickleFilter
• Runtime

The idea is that the new API (loadSources, runCucumber etc) serves these use cases better and removing them from our entry point will enable us to refactor the internals to make Cucumber leaner and more modular.

The deprecations will be fairly long-running - it's going to be a year or more before we actually remove these things, and it will be in a major version - and in the meantime I'm happy to hear any feedback around gaps/flaws in the API functionality and help out with migrations.

---

Relatedly, there's a couple more things currently on the main entry point which would be good to see if we can serve better with the API, this time around support code:

• supportCodeLibraryBuilder
• TestCaseHookDefinition

From what I can see looking at usages in public projects, there is at least:

• Reporting in custom formatters (TestCaseHookDefinition) - now we have hook and stepDefinition messages for this though
• Adding extra support code that's ordering-sensitive e.g a Before hook that should run before all the user's own - maybe we need Before.first() or something?

Thoughts welcome @binarymist @christian-bromann @jan-molak @nicojs

[mrsenzy]

@davidjgoss -- is there way for Programmatically rerun failed scenarios. how the @rerun.txt has to be passed to runCucumber

[davidjgoss]

See the rerun docs at https://github.com/cucumber/cucumber-js/blob/main/docs/rerun.md for the normal configuration of rerun.

To reference the rerun file when calling runCucumber, you could do something like:

import { loadConfiguration, runCucumber } from '@cucumber/cucumber/api'

const { runConfiguration } = await loadConfiguration({ provided: { paths: '@rerun.txt' } })
const result = await runCucumber(runConfiguration)

[davidjgoss]

Closing this off now as the API has been around a while. Feel free to raise an issue if needed!