Adding Parameter for "Alternative Text"

[haibkhn]

🤔 What's the problem you're trying to solve?

When working with Cucumber Expressions, there are cases where we need to choose between a fixed set of alternatives while still capturing which specific alternative was used. Currently, there's no intuitive way to do this without resorting to regular expressions or custom parameter types.

✨ What's your proposed solution?

Introduce a new syntax for alternative text that also acts as a parameter. Instead of the current option1/option2, we propose {option1/option2}. This would allow the expression to match any of the specified alternatives while also capturing the chosen word as a parameter.

Example usages:

UI Interaction

When I {click/hover over/right-click} the {button/link/icon} on the page

Data Manipulation

Then the system should {create/update/delete} the record in the database

API Testing

When I send a {GET/POST/PUT/DELETE} request to the endpoint

User Permissions

Given the user has {read/write/admin} access to the document

State Changes

Then the item status should change to {pending/approved/rejected}

Corresponding step definitions:

When('I {click/hover over/right-click} the {button/link/icon} on the page', (action, element) => {
  // action will be "click", "hover over", or "right-click"
  // element will be "button", "link", or "icon"
  // ...
})

Then('the system should {create/update/delete} the record in the database', (operation) => {
  // operation will be "create", "update", or "delete"
  // ...
})

When('I send a {GET/POST/PUT/DELETE} request to the endpoint', (method) => {
  // method will be "GET", "POST", "PUT", or "DELETE"
  // ...
})

Given('the user has {read/write/admin} access to the document', (accessLevel) => {
  // accessLevel will be "read", "write", or "admin"
  // ...
})

Then('the item status should change to {pending/approved/rejected}', (newStatus) => {
  // newStatus will be "pending", "approved", or "rejected"
  // ...
})

This syntax would be more intuitive and expressive than current alternatives, especially for scenarios with a limited set of valid options.

⛏ Have you considered any alternatives or workarounds?

Custom Parameter Types: While it's possible to create custom parameter types, this approach is less intuitive and requires more setup. It also doesn't clearly communicate the limited set of valid options in the expression itself.

📚 Any additional context?

No response

[mpkorstanje]

I don't think this is something we'd be interested in supporting. Typically when parsing a fixed set of alternatives, these map to an enum rather than a string. This type conversion requires a converter, so having a dedicated syntax to capture strings wouldn't add much.

I'll leave this open for now to see if there is more interest.

[luke-hill]

One thing to bare in mind here is the capture statements are only valid if the capturing parameter type is already created with a 'blank' transformer. i.e. 'abc' => 'abc'.

Given this parameter type already exists, making it a slightly more complex one feels the logical path imo. So you should create one for {crud-action} one for {ui-action} e.t.c.