Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FTR] Add Gherkin feature spec support #63892

Closed
spalger opened this issue Apr 17, 2020 · 3 comments
Closed

[FTR] Add Gherkin feature spec support #63892

spalger opened this issue Apr 17, 2020 · 3 comments
Labels
Feature:Functional Testing Team:Operations Team label for Operations Team

Comments

@spalger
Copy link
Contributor

spalger commented Apr 17, 2020

The uptime team would like to start using the Gherkin language to describe features to replicate the BDD style supported by cucumber. Adding support for this to the functional test runner would allow them to write feature specs in Gherkin syntax like below:

# https://github.com/elastic/kibana/blob/master/x-pack/legacy/plugins/apm/e2e/cypress/integration/apm.feature
Feature: APM

  Scenario: Transaction duration charts
    Given a user browses the APM UI application
    When the user inspects the opbeans-node service
    Then should redirect to correct path with correct params
      And should have correct y-axis ticks

This is paired with JavaScript files that define what should happen at each step defined, similar to below:

const PageObjects = getPageObjects(['common']);

Given('a user browses the APM UI application', async () => {
  await PageObjects.common.navigateToApp('apm')
});

// ... more definitions

The idea is that the functional test runner configs could enable "bdd feature testing", or something similar, and then the functional test runner would parse the features/**/*.feature files next to the config file and convert them into tests that the FTR knows how to execute, pulling in the logic defined by step definitions in step_definitions/**/*.{js,ts} (relative to the config file again).

This would allow us to experiment with this new structure for defining tests while reusing the existing functional test runner services/reporting/integrations and allow teams to adopt this style of defining tests if they wish.

cc: @mdelapenya

@spalger spalger added Team:Operations Team label for Operations Team Feature:Functional Testing labels Apr 17, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-operations (Team:Operations)

@mdelapenya
Copy link
Contributor

Hi 👋! Is there any progress on this issue? Please let me know if there is anything I can do on my end to push this feature into FTR

Cheers!

@tylersmalley tylersmalley added 1 and removed 1 labels Oct 11, 2021
@exalate-issue-sync exalate-issue-sync bot added impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. loe:small Small Level of Effort labels Oct 12, 2021
@tylersmalley tylersmalley removed loe:small Small Level of Effort impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. EnableJiraSync labels Mar 16, 2022
@tylersmalley
Copy link
Contributor

We're working on defining the requirements to replace the functional test runner, so it's unlikely that this change will be made to the existing FTR. I have added it to our project spec doc and will share it when it's ready.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Functional Testing Team:Operations Team label for Operations Team
Projects
None yet
Development

No branches or pull requests

4 participants