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