Cucumber-js: 제안: 오이-js 실행을 위한 프로그래밍 API

초기 피드백을 위한 페이징: @aslakhellesoy @charlierudolph @aurelien- reeves @mattwynne @nicojs @jan-molak

나는 이 제안을 좋아한다! 우리는 이미 fake-cucumber의 runCucumber 에서 이와 같은 API를 사용하고 있습니다.

@davidjgoss - 잘 들립니다!

참고로 Serenity/JS가 현재 Cucumber를 호출하는 방법은 다음과 같습니다. CucumberCLIAdapter
그리고 다음은 구성 매개변수를 argv - CucumberOptions 로 변환하는 논리입니다.

argv 대신 options 객체를 제공할 수 있다면 훨씬 좋을 것입니다 👍🏻

사랑해!

새로운 공개 API를 지정하는 동안 문제 #1489에서 최근에 발생한 일을 고려하고 테스트 중인 필터 및 결과 기능과 더 많은 상호 작용을 하기 위해 공개 API를 제공하는 것에 대해 생각할 수도 있습니다.

여기에 덧붙여서 Cucumber-Electron도 쉽게 만들 수 있는 것을 만들어 보겠습니다.

• 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

공개 API가 있는 것이 없는 것보다 낫습니다. 계속하세요 👍!

바람직하게는 cucumber-js 와 동일한 규칙을 사용하여 프로필을 로드하는 API를 사용하여 일반적인 cucumber-js 호출의 정확한 동작을 모방할 수 있습니다.

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

StrykerJS는 또한 custom_formatters API와 eventBroadcaster 게시한 이벤트에 크게 의존합니다. 공개 API에도 추가할 수 있습니까? 참조: https://github.com/stryker-mutator/stryker-js/blob/03b1f20ed933d3a50b52022cfe363c606c2b16c5/packages/cucumber-runner/src/stryker-formatter.ts#L45 -L69

가능하면 나는 오이-js와 동일한 규칙을 사용하여 프로필을 로드하는 API를 가지고 있어 일반적인 오이-js 호출의 정확한 동작을 모방할 수 있습니다.

이것은 좋은 점입니다. 프로필(최소한 현재 형식)은 기본적으로 CLI에 연결되어 있으므로 경계의 측면에 유지하는 것이 옳다고 생각하지만 여전히 프로필을 로드하고 부분 옵션 개체를 생성하는 기능을 노출할 수 있습니다.

새로운 공개 API를 지정하는 동안 문제 #1489에서 최근에 발생한 일을 고려하고 테스트 중인 필터 및 결과 기능과 더 많은 상호 작용을 하기 위해 공개 API를 제공하는 것에 대해 생각할 수도 있습니다.

API를 호출할 때 사용자 지정 피클 필터를 제공하는 옵션을 포함할 수 있다고 생각합니다(내장 필터링을 구동하는 이름, 태그 등).

매우 command-line-y인 경우 프로필에 대한 현재 구문입니다.

JSON, JavaScript, YAML 또는 환경 변수와 같은 보다 일반적인 형식으로 프로필을 지정할 수 있으면 ❤️❤️❤️. JSON에서는 다음과 같이 보일 수 있습니다.

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

또는 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
  }
}

또는 환경 변수가 있는 경우(예: 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

사실, config 라이브러리는 정확히 이것을 합니다. 다른 것들이 방해가 되었기 때문에 우리는 그것을 Cucumber-JVM에 통합하는 것으로 끝내지 못했지만 JavaScript 구현으로 시도해 볼 수는 없을까요?

@aslakhellesoy 는 그것이 굉장할 것이라는 데 동의합니다! 이 제안에 대해 POC를 진행하도록 하여 좀 더 구체적으로 이야기할 수 있는 내용이 있고 그 일부로 프로필을 올바르게 만들고 싶습니다(4.5년, #751 😄).

참조 #1004

이것은 좋은 점입니다. 프로필(최소한 현재 형식)은 기본적으로 CLI에 연결되어 있으므로 경계의 측면에 유지하는 것이 옳다고 생각하지만 여전히 프로필을 로드하고 부분 옵션 개체를 생성하는 기능을 노출할 수 있습니다.

예, 플러그인 제작자의 관점에서 보면 대단하고 감사할 일입니다.

JSON, JavaScript, YAML 또는 환경 변수와 같은 보다 일반적인 형식으로 프로필을 지정할 수 있으면 ❤️❤️❤️. JSON에서는 다음과 같이 보일 수 있습니다.

그거 좋을 거 같아! 그리고 이것이 바로 내가 오이JS와 같은 방식으로 API를 로드할 수 있는 API를 고맙게 여기는 이유이기도 합니다. 단일 cucumber.js 파일을 로드하는 것은 간단합니다. 우선 순위, 파일 형식 등을 포함하여 구성 파일 로드 알고리즘을 복제하고 유지 관리하는 것은 완전히 다른 것입니다 😅.

Q: 필요 캐시를 지우지 않고 _ runCucumber 를 연속으로 두 번 실행할 수 있습니까? 이것은 돌연변이 테스트 사용 사례에서 중요합니다.

우리는 활성 돌연변이를 전환하기 위해 전역 변수를 변경하면서 환경을 로드하고 테스트를 빠르게 연속적으로 여러 번 실행하려고 합니다.

지금 우리는 cli 개인 API를 사용 하고 있으며 각 테스트 실행 사이에 require.cache 에서 단계 정의 파일을 지워야 합니다. 이것은 CommonJS에 이상적이지 않으며 esm에서는 전혀 작동하지 않습니다.

사용 사례의 의사 코드:

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 는 우리가 이것이 필요하다는 데 동의합니다. 예를 들어 람다에서 오이를 실행하려는 사람들과 함께 이전에 몇 번

지금까지 스케치한 것은 기능적인 스타일에 가깝지만 기본 개념은 다음과 같습니다.

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

그것은 우리에게 효과가 있습니다 👍

우리에게도 효과가 있습니다 👍🏻

나는 이와 같은 것이 오늘날 우리가 테스트 도구 통합(Jest, Cypress)으로 인해 겪고 있는 큰 혼란에 대한 대안으로 매우 유용할 것이라고 생각합니다. 예를 들어 다음과 같은 문제를 발견했습니다(중요한 순서대로).

• cypress-cucumber-preprocessor 는 예제의 태그를 지원하지 않습니다(https://github.com/TheBrainFamily/cypress-cucumber-preprocessor/issues/196).
• jest-cucumber 는 Cucumber JSON 보고를 지원하지 않습니다(https://github.com/bencompton/jest-cucumber/issues/27).
• cypress-cucumber-preprocessor 는 집계에 대한 공식 지원 없이 여러 Cucumber JSON 보고서를 생성합니다(https://github.com/TheBrainFamily/cypress-cucumber-preprocessor/issues/423).
• jest-cucumber 은 jest-cucumber-fusion 만큼 편리하지 않습니다.
• cucumber-jest ...
• Karma에는 더 이상 작동하는 구현이 없습니다(https://github.com/cucumber/cucumber-js/issues/1095).

차라리 Jest/Karma/Cypress/etc 사이에 최소한의 글루 코드를 보고 싶습니다. 그리고 오이-js를 사용하므로 사용해야 하는 누락된 기능으로 인해 고통을 겪을 필요가 없습니다.

좋은 제안 @davidjgoss 👍

명령줄 사용자 인터페이스와 테스트로 시나리오를 구문 분석하고 실행하는 "비즈니스 로직" 사이의 이러한 분리는 육각형 아키텍처 패턴을 생각나게 합니다.

오이-루비에서 우리는 "클린 룸"에서 처음부터 다시 빌드했기 때문에 실제로 핵심 도메인 로직(또는 "내부 육각형")을 별도의 gem 패키지로 분할했습니다. 나는 그것이 여기서 컨텍스트가 아니라는 것을 알고 있지만 영감을 얻거나 이 디자인의 혁신을 Ruby API에 피드백하는 것이 가치가 있을 수 있습니다. 해당 API를 사용하는 방법에 대한 오이-루비-코어 보석의 README에 예가 있습니다.

자, 여기 "실행" 비트에 대한 API 서명의 첫 번째 패스가 있습니다. 이것은 우리가 내부적으로 가지고 있는 IConfiguration 객체에 크게 기반을 두고 있지만(아래로 너무 많은 리팩토링을 일으키지 않아야 함) "평평한" 정도는 조금 덜합니다.

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
}

그리고 매우 인위적인 사용 예:

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

피드백 환영합니다! 이것은 또 다른 기능이 될 프로필/구성 로딩을 다루지 않는다는 점에 유의하십시오.

나는 이것이 좋아 보인다고 생각합니다. 질문: 사용자 지정 포맷터를 어떻게 구성합니까?

@nicojs 는 CLI와 비슷합니다.

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

@davidjgoss의 진행 상황을 보니 반갑습니다!

이 작업의 진행 속도를 늦추고 싶지는 않지만 동시에 다른 Cucumber 구현에서도 작동할 수 있는 형식을 채택하고 싶습니다.

결국 JSON 스키마이지만, 논의하는 동안 TypeScript 유형이 우리 인간이 구문 분석하기 더 쉽다고 생각합니다.

cucumber/common 모노레포에서 제안된 형식에 대한 새 문제를 만들고 핵심 팀을 초대하여 토론하도록 제안합니다.

@aslakhellesoy 가 할 것입니다.

프로그래밍 방식 API가 공통 옵션 구조에 연결되지 않는 것에 대해 어떻게 생각하십니까? runCucumber 옵션에 매핑하는 것과 같습니다. 약간의 복잡성이 추가될 수 있지만 로드할 매개변수이거나 이전에 로드된 지원 코드 라이브러리인 support 블록이 있다는 점에서 매력적입니다. 기능 + 피클에 대해서도 유사한 작업을 수행할 수 있습니다. 프로그래밍 방식 API에는 적합하지 않은 다양한 옵션(예: --exit )이 CLI에서 지원됩니다.

프로그래밍 방식 API가 공통 옵션 구조에 연결되지 않는 것에 대해 어떻게 생각하십니까?

옵션 파일 내용을 runCucumber 원하는 데이터 구조로 변환하는 함수를 제공하는 한 괜찮다고 생각합니다.

결국 JSON 스키마이지만, 논의하는 동안 TypeScript 유형이 우리 인간이 구문 분석하기 더 쉽다고 생각합니다.

우리는 왜 선택해야 합니까? StrykerJS에서 JSON 스키마를 사용하여 json-schema-to-typescript를 사용하여 typescript를 생성하고 있습니다. TS 출력 파일을 소스 제어에 커밋하지 않고 대신 prebuild 단계를 사용하여 즉석에서 생성합니다.

JSON 스키마는 여전히 인간 IMO에서 어느 정도 읽을 수 있습니다. 우리는 이미 Stryker 리포지토리에서 PR을 받았고 사람들은 무엇을 해야 하는지 알고 있는 것 같습니다 🤷‍♀️

CLI에서와 같이

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

출력 파일 이름이 필요하지 않은 기자에게 이것이 어떻게 작동할까요? 이렇게:

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

우리는 왜 선택해야 합니까?

구성 구조에 대한 단일 정보 소스로 JSON 스키마를 사용해야 한다고 생각합니다. - 그런 다음 해당 스키마에서 TypeScript/Java/Whatever 코드를 생성합니다.

그러나 JSON 스키마는 사람이 읽기에 약간 어렵습니다. 따라서 cucumber/common 의 GitHub 문제에서 스키마에 대해 논의 하는 동안

무슨 말인지 알겠어?

JSON 스키마는 여전히 사람이 읽을 수 있습니다. IMO

나에게는 아닙니다 :-) 너무 장황합니다.

출력 파일 이름이 필요하지 않은 기자에게 이것이 어떻게 작동할까요?

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

(하나의 포맷터만 stdout 스트림을 사용할 수 있음)