This document discusses Behavior-Driven Development (BDD), which is a software engineering practice that uses concrete examples to build a common understanding of how features should be implemented to deliver business value. BDD motivates teams to specify features by working with customers to develop executable documentation in the form of acceptance tests written in a natural language format. This approach facilitates communication between technical and non-technical stakeholders and helps ensure the delivered system meets the customer's needs. Tools like Cucumber automate the execution of acceptance tests written in a behavior-driven style to help validate features and provide living documentation.

1. BEHAVIOR-DRIVEN
DEVELOPMENT
…………………………………………………………………………………………
………….
AUTOMATE YOUR REQUIREMENTS

2. Some hashtags about me
Andrey Kovalskiy
EPAM Kazakhstan
Java developer
#j2ee
#agile
#tdd
#xp
#cleancode?
www.facebook.com/andrey.kovalskiy.91

3. Why am I here?
DEV
QArelease
 ~ 0% bugs on production
 Happy customer
 We are protected from further bugs
 Impressed QA team 
then
now

4. We did it! How?
 TDD
 Right test pyramid
 Continuous integration
 Code review
 Pair programming
 SonarQube
 Monkey testing
 Awesome product owner

5. Right test pyramid
UI
System
Integration
Unit
Selenide
JUnit
DBUnit
Some BDD framework

6. Some statistics
 Code coverage by Unit tests: 91.8%
 Code coverage by integration tests: 86.4%
 Acceptance tests’ execution time: 2h 10min
 System tests’ execution time: 4 min
 Integration tests’ execution time:
 Total build time: 13 min

7. Agile methodology

8. “Software requirements
is a communication problem.”
Mike Cohn. User Stories Applied, 2004

9. Perception distinction
QA team Dev team Customer

10. Customer domination
Customer
QA girls
Dev team lead

11. Team work

12. “Specifications written in natural
language are, as it turns out, a
terribly poor way of communicating
requirements…”
John Ferguson Smart. BDD in Action, 2015, ch.1, p.19

13. build a wall
bring a confrontation
Specifications
leave a place for
assumptions

14. John Ferguson Smart. BDD in Action, 2015, ch.1, p.5

15. Example
Specification vs. Examples
Specification
Take one lace in each hand and
make an X
Make a loop out of each lace
Cross the bunny ears over each
other
Run the bunny ears over each
other
See the bunny jump in a hole
Pull loops tight

16. Story card
User Story
Users should be able to
pay with credit card
Acceptance tests
Test with Visa
Test with MasterCard
Test with unsupported card
Test when out of the limit
story card face story card back

17. Why acceptance tests?
• Allow to communicate details
• Insure that customer and the team has equal understanding
• Ensure that you build right system
• Express acceptance criteria
• Explains what the system does so it can be changed easily

18. Concrete examples
Scenario: New user, suspicious transaction
Given a user with no previous transaction history,�
And the user’s account registration country is the UK,�
When the user places an order with delivery country
U.S.,�
Then the transaction is marked as suspicious,�
But the user sees order status as “Pending.”
Gojko Adzic. Specification by Example, 2011, ch.8, p.129

19. That is what BDD about
Behavior-Driven Development (BDD) is a software engineering practice
which motivates a team to use
concrete examples
to build up a common clear understanding of how features should be
implemented to
deliver a real business value
and
reach business goals.

20. BDD principles
Work together to specify features
Focus on features that delivers business values
Let customer develop a design solution instead of requirements
Don’t write tests, write executable documentation
Deliver living documentation

21. John Ferguson Smart. BDD in Action, 2015, ch.1, p.6

22. BDD automation tools
• JBehave
• Cucumber
• SPOCK
• Easyb

23. Cucumber
A testing framework to run tests
written in behavior-driven development (BDD) style.
Gherkin feature files
Big community

24. Gherkin
Business Readable, Domain Specific Language
 Feature
 Background
 Given
 When
 Then
 And
 But

25. Feature file

26. Step definitions

27. Test runner

28. Tests in action

29. Hooks
 @Before
 @After
 Are relative to the scenarios
 Should not be mixed with JUnit annotations
 May be tagged

30. Html reports

31. BDD benefits
Effective communication
Delivering features valued by customer
Higher customer involvement into design process
Living documentation
Safer and easier changes

32. BDD difficulties
Requires high business engagement and collaboration
Hard to involve customer
Poor written tests can lead to higher maintenance costs (∆)

33. Sources
GitHub: https://github.com/jugkaraganda/bdd

34. Thank you