BDD
Agenda
- What is TDD?
- TDD rules
- TDD pros/cons
- How BDD differs?
- BDD key principles
- Business value understanding issues
- Gherkin
- Organizing steps and scenarios
- BDD antipaterns
- BDD disadvantages
- BDD tools
What is Test Driven Development(TDD)?
TDD rules?
You are not allowed to write any production code unless it is to make a failing unit test pass
You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures
You are not allowed to write any more production code than is sufficient to pass the one failing unit test
TDD GOALS
- ensure that source code is thoroughly tested
- ensure that the application is written for testability
- enable safe refactoring
- provide early understanding of the product requirements
- provide a working specification of your functional code
- less manual testing
- reduce bug fixing time
TDD Pros
- large numbers of tests help to limit the number of defects in the code
- can lead to more modularized, flexible, and extensible code
- automated test save a lot of time compared to manually testing functionality
- reduced time allocated for regression testing
- tests written ahead of time will also ensure good code quality
- tests serve as a living documentation
- time of running and manually testing your application
TDD cons
- may not be right for developers who mostly work with a non-TDD approach
- promotes Microdesign over Macrodesign
- complex scenarios requiring a greater time investment
- rapidly changing requirements makes creation and maintenance of these tests onerous
- requires more time for maintaining tests
- the tests may be hard to write, esp. beyond the unit testing level
- hard to apply to existing legacy code
- whole system can quickly degrade unless everyone on the team correctly maintains their tests
- too detail focused and without broader picture
How is BDD different from TDD?
- BDD isn’t about the tools. It’s about the conversations you have
- bridge the communication gap between development and business
- conversations are documented using concrete examples in a language we call Gherkin
- solves the more complex communication problems that are (by definition) beyond the scope of TDD
- creates a common understanding
- It is a way to describe the behavior of a system and a way to make sure that it is developed to behave as it should
- living documentation understandable by non technical people
Key principles
- Enough is enough
- Deliver stakeholder value
- It’s all behavior
- Reduced waste
- Reduced costs
- Easier and safer changes
- Faster releases
Business value understanding issues
- Traditional specifications issues
- Written communication
- Cooperation
- Feedback cycles
- Any conversations are just as bad as writing a specification using a word processor
BDD isn’t about the tools. It’s about the conversations you have
What can we do about it?
- Specification by Example
- Simplify the specification
- Test the specification
-
Three amigos session involving
- Business - What problem are we trying to solve?
- Development - How might we build a solution to solve that problem?
-
Testing - What about this, what could possibly happen?
- Faster feedback
Where should you use it?
Gherkin
- everyone can read and understand examples
- executable
- acting as an acceptance criteria
A formal language fulfilling the requirements that a good specification is:
Feature: Google Searching As a web surfer, I want to search Google, so that I can learn new things. Scenario: Simple Google search Given a web browser is on the Google page When the search phrase "panda" is entered Then results for "panda" are shown And the related results include "Panda Express" But the related results do not include "pandemonium"
Feature: Google Searching
As a web surfer, I want to search Google, so that I can learn new things.
Background:
Given a web browser is on the Google page
Scenario: Simple Google search for pandas
When the search phrase "panda" is entered
Then results for "panda" are shown
Scenario: Simple Google search for elephants
When the search phrase "elephant" is entered
Then results for "elephant" are shown
Scenario: Simple Google search for elephants
When the search phrase "elephant" is entered
Then results for "elephant" are shown
Examples: Phrases
| phrase |
| panda |
| elephant |
Scenario: Simple Google search
When the search phrase "panda" is entered
Then results for "panda" are shown
And the following related results are shown
| related |
| Panda Express |
| giant panda |
| panda videos |
Gherkin scenarios - good properties
- Outcome
- Concrete
- No implementation details
- No irrelevant details
- Hide unimportant setup
- Good diagnosis precision
- Connect as a real user
Organizing steps and scenarios
- Group steps by model
- Each step definition file should support one domain concept
- Group features by…feature
- Avoid feature coupled step definitions
- Avoid conjunction steps
- Be DRY: Refactor and Reuse Step Definitions
BDD antipaterns
- Bad collaboration
- Business people create scenarios in isolation
- Devs or testers writing scenarios without talking to business people
- Too high level
- No living documentation
- When you read Gherkin and it is bad documentation
- Incidental details
- Testing multiple things at the same time
- Bad name on a scenario
- Lots of user interface details
- Keeping all scenarios forever
- No clear separation between
Disadvantages and potential challenges
- Requires high business engagement and collaboration
- Works best in an Agile or iterative context
- Doesn’t work well in a silo
- Poorly written tests can lead to higher test-maintenance costs
- BDD requires scripting skills
- Preparation of tests may take 20-30% more time
Questions?
BDD tools
References
BDD
By Igor Sosnovskyy
BDD
- 224