- Feature Step: the textual descriptions which form the body of a scenario
- Step Definition: matcher methods, implementation of a step.
- composed of a regexp and a block, which receives all of the matched elements as arguments
- Feature: indivisible unit of functionality, e.g. an authentication challenge and response user interface. Each Feature is composed of Scenarios
- Scenario: a block of statements inside a feature file that describe some behaviour desired or deprecated in the feature
- Use descriptive, instead of procedural feature steps
- Feature steps are about what needs to happen, not how
- Will this wording need to change if the implementation does?
- The verb used in the step definition doesn’t matter:
- A Given feature clause can match a When step definition matcher.
- The physical directory structure is flattened by Cucumber
- any file ending in
.rb is loaded
- steps defined in one file can be used in any feature
- name clashes result in errors
-r parameter instead allows to selectively load files/directories
- Immediately implement the new step requirement in the application using the absolute minimum code that will satisfy it.
- The result is that you will never have untested code in your app
- Because all code is a product of a test
modules to group together calls to the Capybara API
- Cucumber uses transactions, and transactions are rolled-back after each
- For each feature step
- Write step definition
- Run, and watch it fail
- Write application code that makes it pass
- Without changing the step’s logic, change the “test criteria”, to make sure it’s passing for the right reason
- Reset the “test criteria”
A Good Step Definition
- The matcher is short.
- The matcher handles both positive and negative (true and false) conditions.
- The matcher has at most two value parameters
- The parameter variables are clearly named
- The body is less than ten lines of code
- The body does not call other steps