-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Upgrade to Cucumber Expressions 3.0.0 #764
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
Changes from 7 commits
dbdca3b
bfecc83
e53b416
ba63857
e6d5495
afed98d
72c3d4a
6815c0f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -3,3 +3,4 @@ | |
lib/ | ||
node_modules | ||
usage.txt | ||
.idea/ | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can you please remove this? I strongly agree with @jbpros and would prefer to take that opportunity to teach people to use their local global gitignore. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,69 @@ | ||
Feature: Custom Parameter | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Please use There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Actually looks like this was done in one of the following PRs so this can be ignored. |
||
|
||
Users can register their own parameters to be used in Cucumber expressions. | ||
Custom parameters can be used to match certain patterns, and optionally to | ||
transform the matched value into a custom type. | ||
|
||
Background: | ||
Given a file named "features/passing_steps.feature" with: | ||
""" | ||
Feature: a feature | ||
Scenario: a scenario | ||
Given a passing step | ||
""" | ||
|
||
Scenario: custom parameter | ||
Given a file named "features/step_definitions/passing_steps.js" with: | ||
""" | ||
import assert from 'assert' | ||
import {defineSupportCode} from 'cucumber' | ||
defineSupportCode(({Given, defineParameterType}) => { | ||
defineParameterType({ | ||
regexp: /passing|failing|undefined|pending/, | ||
transformer: s => s.toUpperCase(), | ||
typeName: 'status' | ||
}) | ||
Given('a {status} step', function(status) { | ||
assert.equal(status, 'PASSING') | ||
}) | ||
}) | ||
""" | ||
When I run cucumber.js | ||
Then the step "a passing step" has status "passed" | ||
|
||
Scenario: custom parameter without transformer | ||
Given a file named "features/step_definitions/passing_steps.js" with: | ||
""" | ||
import assert from 'assert' | ||
import {defineSupportCode} from 'cucumber' | ||
defineSupportCode(({Given, defineParameterType}) => { | ||
defineParameterType({ | ||
regexp: /passing|failing|undefined|pending/, | ||
typeName: 'status' | ||
}) | ||
Given('a {status} step', function(status) { | ||
assert.equal(status, 'passing') | ||
}) | ||
}) | ||
""" | ||
When I run cucumber.js | ||
Then the step "a passing step" has status "passed" | ||
|
||
Scenario: custom parameter (legacy API) | ||
Given a file named "features/step_definitions/passing_steps.js" with: | ||
""" | ||
import assert from 'assert' | ||
import {defineSupportCode} from 'cucumber' | ||
defineSupportCode(({Given, addTransform}) => { | ||
addTransform({ | ||
captureGroupRegexps: /passing|failing|undefined|pending/, | ||
transformer: s => s.toUpperCase(), | ||
typeName: 'status' | ||
}) | ||
Given('a {status} step', function(status) { | ||
assert.equal(status, 'PASSING') | ||
}) | ||
}) | ||
""" | ||
When I run cucumber.js | ||
Then the step "a passing step" has status "passed" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer if we avoided IDE-specific exclusions.
It's often recommended to do that locally so that we don't have to worry about everyone's preferred IDEs/editors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we add it to the repo, then we don't have to worry about some git noob adding their whole IDE config folder in a PR.
Is this really worth worrying about?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If a "git noob" sends a PR with the whole
.idea
folder checked in, it would be a great opportunity to teach them a bit more about Git 👍But no, it's probably not worth discussing any further. I told you my preference, you decide.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm with @jbpros here. I believe anything that is not universal to this project belongs in your local global gitignore.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just my two cents: We don't have to "worry" about everyone's preferred IDE, if we just accept their addition to the gitignore whenever it comes. Also, I'm guessing this won't be the last time someone tries to add
.idea/
to the gitignore.But I agree, either way this isn't worth worrying about lol