On that same page is Gherkin which is what both examples are. (I may have gotten the syntax slightly wrong.) Cucumber uses Gherkin. I forget which is which exactly. Maybe Cucumber is the code that reads Gherkin and executes step definitions.
For whatever reason, people try to make a small number of extremely flexible step definitions which leads to scenarios that don’t actually read as business requirements. (Which is the entire point in the first place.)
Given a user has a bank accout
And the account has a balance of $10
When the user attempts to withdraw $20
Then the transaction should fail
And the account should have a balance of $20
Given a user has a bank accout
And the account has a balance of $10
When the user attempts to withdraw $5
Then the transaction should succeed
And the account should have a balance of $5
Given a user has a bank accout
And the account has a balance of $10
When the user attempts to deposit $5
Then the transaction should succeed
And the account should have a balance of $15
Doing something like this is more elegant. The steps definitions would be
a user has a bank account performs setup tasks to load a test user into the system.
the account has a balance of X would either load the account with that much or just make an initial deposit.
the user attempts to withdraw X/the user attempts to deposit X would both perform those actions. If it’s a web API they’d be HTTP requests.
then the transaction should X would check HTTP status code. You could make this two separate step definitions or have logic based on the word. Two separate step definitions is probably better.
the account should have a balance of X checks the balance in the account.
Your (verbose and harder to understand) example reminds me of https://jbehave.org/reference/stable/story-syntax.html
On that same page is Gherkin which is what both examples are. (I may have gotten the syntax slightly wrong.) Cucumber uses Gherkin. I forget which is which exactly. Maybe Cucumber is the code that reads Gherkin and executes step definitions.
For whatever reason, people try to make a small number of extremely flexible step definitions which leads to scenarios that don’t actually read as business requirements. (Which is the entire point in the first place.)
Doing something like this is more elegant. The steps definitions would be
a user has a bank accountperforms setup tasks to load a test user into the system.the account has a balance of Xwould either load the account with that much or just make an initial deposit.the user attempts to withdraw X/the user attempts to deposit Xwould both perform those actions. If it’s a web API they’d be HTTP requests.then the transaction should Xwould check HTTP status code. You could make this two separate step definitions or have logic based on the word. Two separate step definitions is probably better.the account should have a balance of Xchecks the balance in the account.