PicPay - GenAI Finance Assistant - ChatGPT for Customer Service
ATDD in practice
1. ATDD in practice
Andrei Marukovich
andrei.marukovich@lunarfrog.com
Twitter @amarukovich
:
Blog: lunarfrog.com/blog
2. Agenda
• What is Acceptance Test Driven
Development?
• ATDD in depth
• SpecFlow demo
2
3. Story of ProjectX
• Ingredients of success
• Dedicated team and comfortable schedule
• Continues integration server
• High Unit Tests coverage
• Regular architecture reviews
• Metrics analyzes
3
4. Project was rejected by the customer
“Actually, we asked for something different”
4
5. Reason of the failure
1. Initial
requirements
Sales
Customer
Department
3. Wrong
product
2. Adjusted
Development requirements
Team
Lack of communication
5
6. ATDD is about…
• Communication
• Collaboration
• Process improvements
• Better specifications
6
8. Definition
• TDD helps to develop product right
• ATDD helps to develop right product
• Other names:
• Behavior Driven Development
• Specification by example
• Executable specification
8
9. ATDD and TDD
Refactor Red
TDD
Specify Develop
Green
ATDD
Deliver
9
10. Specify
All stakeholders collaborate on specification
Domain Developers Testers Specification
Define Clarify Verify
Specification based on common
understanding
10
11. Workshop types
• Full team
• Mini-team
• 1 domain expert + 1 developer + 1 tester
• Pairing
• Useful for extending existing specifications
11
13. Specification example
Feature: New user registration
In order to be able to use site
As a new user
I want to be able to register an account
Scenario: Successful registration
Given I am on Registration page
When I entered unique name
And I entered valid password
Then a new account is created
13
14. Executable specification benefits
• Better definition of scope and “done”
• More scenarios identified upfront
• Preventing defects is cheaper than fixing
them
• Prevents system regression
14
15. What to specify
• User Interface?
• Business logic?
• Data access layer?
• Algorithms?
Everything, if it make sense for customer
15
17. How to specify
• Define system behavior, not steps
• Simplifies long term maintenance
• Captures domain knowledge
• Do not rely on implementation details
• Test should be self-describing
• Define allowed and disallowed scenarios
• Provide right and failing examples
• Use iterative approach
• Start with defining of the happy path
• Use domain language
17
23. Gherkin style specification
Feature: New user registration
In order to be able to use site
As a new user
I want to be able to register an account
Scenario: Successful registration
Given I am on Registration page
When I entered unique name
And I entered valid password
Then a new account is created
23
25. Test maintenance
• Automation code is code – follow all good
habits
• Document building blocks
• Split the test – fast, slow, stable
• ATDD can be used for integration but keep
integration and functional tests separately
25
26. Way for a better specifications
• Collaborative approach
• Specify behavior, not implementation
• Testable requirements
• Automate specification tests
• Control specification maintainability
26