Behavior Driven Development Flashcards
Behavior
- How a product or feature operates. Ex.:
- logging into a webpage
- clicking links in nav bar
- submitting forms
- making successful service calls
- receiving expected errors
What is BDD?
- a test-centric software development process that grew out of Test-Driven Development
- has been around since the mid-2000s
- behaviors become the team’s focus
BDD is a refinement of the Agile process, not an overhaul.
True
Advantages of BDD (part 1):
- Inclusion: anyone can write BDD scenarios
- Clarity: focus on expected behavior of product
- Streamlining: requirements = acceptance criteria = test cases. Expedites automation.
Advantages of BDD (part 2):
- Shift-Left: testing early in the development process, results in fewer bugs later
- Artifacts: scenarios form a collection of test cases. Any tests not automated can be added to a known automation backlog.
- Automation: BDD frameworks make it easy to turn scenarios into automated tests
Advantages of BDD (part 3):
- Test Driven: most BDD frameworks can run scenarios to fail until the feature is implemented
- Code Reuse: “Given-When-Then” steps can be reused between scenarios
- Parametrization: steps can be parametrized
Advantages of BDD (part 4):
- Variation: scenario outlines make it easy to run the same scenario with different combinations of inputs
- Momentum: scenarios become easier and faster to write and automate as more step definitions are added
- Adaptability: scenarios are easy to update as the product changes
What types of tests are BDD best suited for?
- Higher level, functional, black box tests
- E.g., testing APIs and web UIs
What types of tests is BDD NOT well-suited for?
- Overkill for unit tests
- Not good for performance tests, which rely on metrics instead of pass/fail results
Gherkin
domain-specific language for writing BDD scenarios whose language standard is maintained by Cucumber (a prevalent BDD automation framework)
Gherkin scenario structure:
Given-When-Then
Given some initial state, when an action is taken, then verify an outcome
Gherkin Features
- has a title and description - only used for documentation purposes
- associated with user stories
- may have one Background section
- may have multiple associated scenarios and scenario outlines
- should only have one Feature per feature file
Gherkin Scenarios
- each scenario is essentially a test case
- each Given/When/Then line is called a step
- steps MUST appear in the Given/When/Then order
How to write good steps:
Good steps are declarative - states what should happen at a high-level
Not imperative - shouldn’t focus on direct, low-level instructions
In a scenario, each type of step is optional.
True
In a scenario, step order matters.
True
Scenarios are dependent on each other to run.
False. Each scenario runs independently.
Additional steps that can be added to Given, When, or Then:
- And: used instead of repeating G/W/T
- But: functions the same as And, but might be easier to read. Interchangeable with And.
Gherkin: And
- used instead of repeating G/W/T
- example: Given-Given-When-Then = Given-And-When-Then
- associated with the immediately preceding step
- order matters
Gherkin: Background
- a section of Given and And statements to run before each scenario
- does not have a title or description
- only one Background for each Feature section
How do you denote parameter names in Gherkin?
< >
Scenario outlines may have multiple Examples tables.
True
What are Examples?
- a section to provide a table of parameter values for a Scenario Outline
- each table row represents a combination of values to test together
- may have any positive number of rows
Gherkin Keywords: | (pipe character)
- table delimeter used for Examples tables and step tables
- use the escape sequence “|” to use pipe characters as text within a column
