Cucumber support through lambdaisland's excellent kaocha-cucumber library. Docstrings are taken from the Cucumber documentation.
To see more details, read the official Cucumber documentation.
Cucumber support through lambdaisland's excellent kaocha-cucumber library. Docstrings are taken from the Cucumber documentation. To see more details, read the official [Cucumber documentation](https://cucumber.io/docs/gherkin/reference).
(And pattern binds & body)An alias for Given, allowing for more fluidly structured examples.
Example: Multiple Givens Given one thing And another thing And yet another thing When I open my eyes Then I should see something But I shouldn't see something else
An alias for Given, allowing for more fluidly structured examples. Example: Multiple Givens Given one thing And another thing And yet another thing When I open my eyes Then I should see something But I shouldn't see something else
(But pattern binds & body)An alias for Given, allowing for more fluidly structured examples.
Example: Multiple Givens Given one thing And another thing And yet another thing When I open my eyes Then I should see something But I shouldn't see something else
An alias for Given, allowing for more fluidly structured examples. Example: Multiple Givens Given one thing And another thing And yet another thing When I open my eyes Then I should see something But I shouldn't see something else
(Given pattern binds & body)Given steps are used to describe the initial context of the system - the scene of the scenario. It is typically something that happened in te past.
When Cucumber executes a Given step, it will configure the system to be in a well-defined state, such as creating and configuring objects or adding data to a test database.
The purpose of Given steps is to put the system in a known state before the user (or external system) starts interacting with the system (in the When steps). Avoid talking about user interaction in Given’s. If you were creating use cases, Given’s would be your preconditions.
It’s okay to have several Given steps (use And or But for number 2 and upwards to make it more readable).
Examples:
Mickey and Minnie have started a game
I am logged in
Joe has a balance of £42
Given steps are used to describe the initial context of the system - the scene of the scenario. It is typically something that happened in te past.
When Cucumber executes a Given step, it will configure the system to be in a well-defined state, such as creating and configuring objects or adding data to a test database.
The purpose of Given steps is to put the system in a known state before the user (or external system) starts interacting with the system (in the When steps). Avoid talking about user interaction in Given’s. If you were creating use cases, Given’s would be your preconditions.
It’s okay to have several Given steps (use And or But for number 2 and upwards to make it more readable).
Examples:
Mickey and Minnie have started a game
I am logged in
Joe has a balance of £42(hook config m _hook-type)Run cucumber tests
Run cucumber tests
(Then pattern binds & body)Then steps are used to describe an expected outcome, or result.
The step definition of a Then step should use an assertion to compare the actual outcome (what the system actually does) to the expected outcome (what the step says the system is supposed to do).
An outcome should be on an observable output. That is, something that comes out of the system (report, user interface, message), and not a behaviour deeply buried inside the system (like a record in a database).
Examples:
See that the guessed word was wrong
Receive an invitation
Card should be swallowed
While it might be tempting to implement Then steps to look in the database - resist that temptation!
You should only verify an outcome that is observable for the user (or external system), and changes to a database are usually not.
Then steps are used to describe an expected outcome, or result.
The step definition of a Then step should use an assertion to compare the actual outcome (what the system actually does) to the expected outcome (what the step says the system is supposed to do).
An outcome should be on an observable output. That is, something that comes out of the system (report, user interface, message), and not a behaviour deeply buried inside the system (like a record in a database).
Examples:
See that the guessed word was wrong
Receive an invitation
Card should be swallowed
While it might be tempting to implement Then steps to look in the database - resist that temptation!
You should only verify an outcome that is observable for the user (or external system), and changes to a database are usually not.(When pattern binds & body)When steps are used to describe an event, or an action. This can be a person interacting with the system, or it can be an event triggered by another system.
Examples:
Guess a word
Invite a friend
Withdraw money
When steps are used to describe an event, or an action. This can be a person interacting with the system, or it can be an event triggered by another system.
Examples:
Guess a word
Invite a friend
Withdraw moneycljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |