Cucumber-js: Proposal: Programmatic API for running cucumber-js

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

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

@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 👍🏻

Love it!

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

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

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

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.

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).

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?

@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 😄)

Refs. #1004

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 😅.

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

@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
})

That works for us 👍

Works for us too 👍🏻

I really think that something like this would be extremely useful as an alternative for the great mess we have today with testing tool integrations (Jest, Cypress), for example I found these problems (in the order of importance):

• cypress-cucumber-preprocessor does not support tags on Examples (https://github.com/TheBrainFamily/cypress-cucumber-preprocessor/issues/196)
• jest-cucumber does not support Cucumber JSON reporting (https://github.com/bencompton/jest-cucumber/issues/27)
• cypress-cucumber-preprocessor generates multiple Cucumber JSON reports with no offical support for aggregation (https://github.com/TheBrainFamily/cypress-cucumber-preprocessor/issues/423)
• jest-cucumber is not as convenient as jest-cucumber-fusion
• there's also cucumber-jest...
• Karma does not have a working implementation anymore (https://github.com/cucumber/cucumber-js/issues/1095)

I would rather see some minimal glue code between Jest/Karma/Cypress/etc. and cucumber-js so I don't have to suffer for all those missing features I need to use.

Great suggestion @davidjgoss 👍

This separation of concerns between the command-line user interface and the "business logic" of parsing and executing scenarios as tests reminds me of the hexagonal architecture pattern.

In cucumber-ruby we actually split the core domain logic (or "inner hexagon") into a separate gem package, as we were rebuilding it from scratch in a "clean room". I realise that's not the context here, but it might be worth drawing some inspiration from, or feeding back innovations from this design into the Ruby API. There's an example in the cucumber-ruby-core gem's README of how to use that API.

Okay, here's a first pass at the API signature for the "run" bit. It's heavily based on the IConfiguration object we have internally (so shouldn't cause too much refactoring lower down) but just a little less "flat":

export interface IRunCucumberOptions {
  cwd: string
  features: {
    defaultDialect?: string
    paths: string[]
  }
  filters: {
    name?: string[]
    tagExpression?: string
  }
  support:
    | {
        transpileWith?: string[]
        paths: string[]
      }
    | ISupportCodeLibrary
  runtime: {
    dryRun?: boolean
    failFast?: boolean
    filterStacktraces?: boolean
    parallel?: {
      count: number
    }
    retry?: {
      count: number
      tagExpression?: string
    }
    strict: boolean
    worldParameters?: any
  }
  formats: {
    stdout: string
    files: Record<string, string>
    options: IParsedArgvFormatOptions
  }
}

export interface IRunResult {
  success: boolean
  support: ISupportCodeLibrary
}

export async function runCucumber(
  options: IRunCucumberOptions
): Promise<IRunResult> {
  // do stuff
}

And a very contrived example usage:

const result = await runCucumber({
  cwd: process.cwd(),
  features: {
    paths: ['features/**/*.feature'],
  },
  filters: {
    name: ['Acme'],
    tagExpression: '@interesting',
  },
  support: {
    transpileWith: ['ts-node'],
    paths: ['features/support/**/*.ts'],
  },
  runtime: {
    failFast: true,
    retry: {
      count: 1,
      tagExpression: '@flaky',
    },
    strict: true,
    worldParameters: {
      foo: 'bar',
    },
  },
  formats: {
    stdout: '@cucumber/pretty-formatter',
    files: {
      'report.html': 'html',
      'TEST-cucumber.xml': 'junit',
    },
    options: {
      printAttachments: false,
    },
  },
})

Feedback welcome! Note this doesn't cover the profile/config loading stuff which would be another function.

I think this looks good. Question: How would I configure a custom formatter?

@nicojs sorta like on the CLI

formats: {
    files: {
      'report.html': './my/fancy-reporter.js',
      'other-report.html': '@me/reporter-package',
    }
  },

Great to see progress on this @davidjgoss!

I don't want to slow down the progress on this, but at the same time I want to make sure we adopt a format that can work for other Cucumber implementations too.

Eventually a JSON schema, but while we discuss it I think TypeScript types are easier for us humans to parse.

I suggest we create a new issue about the proposed format in the cucumber/common monorepo and invite the core team to discuss there.

@aslakhellesoy will do.

What would you think about the programmatic API not being tied to the common options structure? Like we'd map from that to the runCucumber options. It adds maybe a little complexity but appeals because of things like having a support block that's either parameters to load, or a previously loaded support code library. Could do similar for features+pickles too. And there are various options we'd support on the CLI (e.g. --exit) that aren't appropriate on the programmatic API.

What would you think about the programmatic API not being tied to the common options structure?

I think that's fine, as long as we provide a function that converts from the options file contents to the data structure runCucumber wants.

Eventually a JSON schema, but while we discuss it I think TypeScript types are easier for us humans to parse.

Why do we need to choose? We're using JSON schema in StrykerJS to generate typescript using json-schema-to-typescript. We're not committing the TS output files to source control, instead we generate them on the fly using a prebuild step.

JSON schemas are still somewhat readable for humans IMO. We've already had PR's on the Stryker repo and people seem to know what to do 🤷‍♀️

sorta like on the CLI

formats: {
    files: {
      'report.html': './my/fancy-reporter.js',
      'other-report.html': '@me/reporter-package',
    }
  },

How would this work for a reporter that doesn't need an output file name? Like so:

formats: {
  files: {
    '': require.resolve('./my-awesome-stryker-formatter')
  }
}

Why do we need to choose?

I think we should use a JSON Schema as a single source of truth for the structure of the configuration. -And then generate TypeScript/Java/Whatever code from that schema.

But JSON Schema is a bit hard to read for humans, so while we are discussing the schema in a GitHub issue in cucumber/common I was suggesting TypeScript to facilitate the discussion.

See what I mean?

JSON schemas are still somewhat readable for humans IMO

Not to me :-) Too verbose.

How would this work for a reporter that doesn't need an output file name?

formats: {
    stdout: './my-awesome-stryker-formatter',
    files: {
      'report.html': './my/fancy-reporter.js',
      'other-report.html': '@me/reporter-package',
    }
  },

(only one formatter can use the stdout stream)