Tree in the Forest - Managing Details in BDD Scenarios (live2test 2024)
0 likes159 views
Gáspár Nagy presents an in-depth overview of Behavior Driven Development (BDD), emphasizing its utility in understanding and validating business requirements through scenarios. He discusses best practices for writing effective scenarios, including focusing on essential details and using business language, while also advising on the management of technical details within automation code. The document covers types of details relevant to scenario execution and suggests strategies for ensuring clarity and maintainability in scenario design.
![Copyright © Gaspar Nagy
Copyright © Gaspar Nagy
4. Technical details
• Technical details and steps might be
needed to execute a particular business
action (e.g. enter the name to a textbox
with ID “tb1234”)
• These details are bound to the
implementation, not the specification
• Documenting this details in scenarios
requires intensive maintenance
• Push down:
• Identify & express business needs or actions
• Translate these to the technical details in
code (reusable!)
When the user clicks on button
"//*[@id="orders_O293445"]/td[3]/a"
When the user attempts to start changing in
the order
identified
business action](https://image.slidesharecdn.com/20240522-live2test-treeintheforest-gasparnagy-240522083037-fbe0a1c9/85/Tree-in-the-Forest-Managing-Details-in-BDD-Scenarios-live2test-2024-25-320.jpg)
Tree in the Forest - Managing Details in BDD Scenarios (live2test 2024)
- 1. Gáspár Nagy coach • trainer • bdd addict • creator of specflow “The BDD Books” series • https://bddbooks.com @gasparnagy • gaspar@specsolutions.eu Tree in the Forest Managing Details in BDD Scenarios live2test 2024 22th May, 2024
- 2. Copyright © Gaspar Nagy Copyright © Gaspar Nagy bdd addict given.when.then CAUTION! on the stage Gáspár Nagy coach, trainer and bdd addict creator of SpecFlow & Reqnroll gaspar@specsolutions.eu www.specsolutions.eu linkedin.com/in/gasparnagy bddbooks.com b d d a d d i c t . c om
- 4. Copyright © Gaspar Nagy Copyright © Gaspar Nagy Today… • Super brief BDD intro • Scenarios as Tests • Scenarios as Specification • Types of Details • Wrap-up, Q&A
- 5. Copyright © Gaspar Nagy BDD in 3 minutes…
- 6. Copyright © Gaspar Nagy Copyright © Gaspar Nagy The bridge and the lightbulb by Unknown Author is licensed under CC BY-SA REQ APP BDD scenario: bridge between requirements and the solution make tests understandable make requirements testable Scenario: User votes up a question Given a question asked with 2 votes And the user is authenticated When the user votes up the question Then the votes should be changed to 3
- 7. Copyright © Gaspar Nagy Copyright © Gaspar Nagy Behaviour Driven Development is about understanding, documenting & validating business requirements through illustrative scenarios
- 8. Copyright © Gaspar Nagy Copyright © Gaspar Nagy Purposes of scenarios Scenario: The one where… Given some context When perform an action Then the outcome happens automated test implementation phase (test-driven) maintenance phase (regression) BDD is not (only) testing!
- 9. Copyright © Gaspar Nagy Scenarios as Tests
- 10. Copyright © Gaspar Nagy Copyright © Gaspar Nagy All details that are required for exercising the application has to be available during execution latest
- 11. Copyright © Gaspar Nagy Copyright © Gaspar Nagy This brings up a couple of interesting questions… • What are those details? What kind of details we should consider? • How do we agree on those details? • Where do we document (store/code) those details?
- 12. Copyright © Gaspar Nagy Copyright © Gaspar Nagy Where to document the details? In the text of the scenario in the feature file In the automation code In external sources (Excel, existing data, etc.) managed by code
- 13. Copyright © Gaspar Nagy Copyright © Gaspar Nagy The details are not removed from the scenario, but pushed down to the code
- 14. Copyright © Gaspar Nagy Scenario Code vs Pro • Visible • Easier test result analysis (debugging) Con • Makes scenario hard to read • Maintainability problems Pro • Easy to reuse • Different abstractions can be defined • Maintainable • Visible during execution (dynamic visibility) Con • Harder to see details in code (static visibility) • Code is not a shared asset Details in Gherkin Details coded or processed by code
- 15. Copyright © Gaspar Nagy Copyright © Gaspar Nagy It is easier to manage details in code, but we need to work extra for visibility
- 16. Copyright © Gaspar Nagy Scenarios as Specification
- 17. Copyright © Gaspar Nagy Copyright © Gaspar Nagy How to make scenarios to good specification • Easy to read, review & discuss • Not too long (brief) • Free of “noise” • Business language (ubiquitous language) • Should only change when the requirement changes • No technical/solution details • Focus on the what (intention) and not the how (steps to achieve) • Concrete, so that the validity can be checked • Contain essential (relevant) details • Contain real/concrete data • Should focus on a single business rule
- 18. Copyright © Gaspar Nagy Copyright © Gaspar Nagy 6 BRIEF principles of good scenarios • Business language — Business terminology aids cross-discipline collaboration • Real data — Using actual data helps reveal assumptions and edge cases • Intention revealing — Describe the desired outcomes, rather than the mechanism of how they are achieved • Essential — Omit any information that doesn’t directly illustrate behaviour • Focused — Each scenario should only illustrate a single rule • Brief — Shorter scenarios are easier to read, understand and maintain
- 19. Copyright © Gaspar Nagy Copyright © Gaspar Nagy What details are essential? There are no fixed guidelines to decide on this… and the answer might be context specific… • The details that influence the outcome (=Then steps) • The details that are relevant for the “rule” (=AC, business rule, requirement) the scenario illustrates (“focuses on”, purpose)
- 20. Copyright © Gaspar Nagy Copyright © Gaspar Nagy Deciding on essential details in scenarios without clear outcome and purpose is not possible You need to fix those first
- 21. Copyright © Gaspar Nagy Types of Details
- 22. Copyright © Gaspar Nagy Copyright © Gaspar Nagy Detail types Scenario Related 1. Entity property 2. Entity existence 3. Hierarchic al data 4. Technical details 5. Contextual details (scenario execution context) Implicit Context Related 6. Baseline 7. Workflow steps 8. System status Note: Not necessary a complete list and there are overlaps
- 23. Copyright © Gaspar Nagy Copyright © Gaspar Nagy 1. Entity property • Many properties of the entity might not be relevant for the scenario • These properties change and extended independently of the scenario • Push down: maintain a default (test) values for the properties of the entities in code Given the customer has an order | status | payment method | issue date | due date | | created | bank_transfer | 7/25/2023 | 8/24/2023 | Given the customer has an order Given the customer has a dispatched order Given the customer has an order | status | | dispatched | used defaults defaults can be overridden
- 24. Copyright © Gaspar Nagy Copyright © Gaspar Nagy 2. Entity existence • The existence of some entities might be required for execution, but not relevant for the outcome (e.g. address record of a customer; customer for an order) • These requirements might change independently of the scenario • Push down: • populate the records with defaults automatically • ensure that all prerequisite is created Given there is a customer And the customer has an address | street | city | | 18 Holyrood Park Road | Edinburgh | Given there is a customer pre-populate with default address Given there is a customer And there is an order of the customer required prerequisites Given there is an order ensure customer prerequisite
- 25. Copyright © Gaspar Nagy Copyright © Gaspar Nagy 4. Technical details • Technical details and steps might be needed to execute a particular business action (e.g. enter the name to a textbox with ID “tb1234”) • These details are bound to the implementation, not the specification • Documenting this details in scenarios requires intensive maintenance • Push down: • Identify & express business needs or actions • Translate these to the technical details in code (reusable!) When the user clicks on button "//*[@id="orders_O293445"]/td[3]/a" When the user attempts to start changing in the order identified business action
- 26. Copyright © Gaspar Nagy Copyright © Gaspar Nagy 5. Contextual details (scenario execution context) • The “story” that the scenario explains might need to introduce details that are referred in later steps – they are part of the scenario execution context • Duplicating these details makes the scenario verbose and hard to understand • Push down: • Store these contextual details in scenario- lifetime storage provided by the BDD framework (World, ScenarioContext) • Resolve the references to these details from the storage Given there is a customer "AA“ And the customer "AA“ has an order "O293445“ When the customer “AA” changes the order "O293445“ Given the customer has an order When they change the order refer to context Given the customer has an order When the customer changes the order can use more explicit form as well
- 27. Copyright © Gaspar Nagy Implicit Context
- 28. Copyright © Gaspar Nagy Copyright © Gaspar Nagy Anatomy of a scenario • Given -> Context • When -> Action (triggering action) • Then -> Outcome The “Given” step(s) specify the context (preconditions, system state) that is required in order to perform the action and verify the outcome. Implicit context: Context that we do not express in the scenario
- 29. Copyright © Gaspar Nagy Copyright © Gaspar Nagy When to use explicit context? Given the Earth is spinning And the system has been started And there are the following products | name | unit price | | Flipchart | 250 | | Sticky Notes | 18 | And there is a customer with a dispatched order ... Assumed Needs automation actions Make it implicit? Yes No Yes, always Assumed Needs automation actions Make it implicit? Yes No Yes, always Yes Yes Yes, always Assumed Needs automation actions Make it implicit? Yes No Yes, always Yes Yes Yes, always Maybe Yes Depends… Assumed Needs automation actions Make it implicit? Yes No Yes, always Yes Maybe Yes, always Maybe Yes Depends… No Yes Never
- 30. Copyright © Gaspar Nagy Implicit Explicit vs Pro • Maintained by code • Can hide technical details Con • Requires team agreement & knowledge to understand the scenarios • Tracking the dependencies in code might be more complex Pro • Can be used to declare essential details • Highlights the necessity of the prerequisite Con • Might cause unnecessary duplication in scenarios • Scenarios require more maintenance • Makes scenarios longer and harder to understand Context Context
- 31. Copyright © Gaspar Nagy Copyright © Gaspar Nagy Context is always present Whether you make it explicit is a team decision, that you might need to document
- 32. Copyright © Gaspar Nagy Copyright © Gaspar Nagy 6. Baseline • The scenarios of a product might need “usual” data for expressing the examples • Many team has an implicit agreement to use the same data over and over, so it might became noise • Push down: • Make a team agreement of “default” test data and make sure those can be used without explicitly listing them • Special scenarios can still override • There might be multiple baseline sets Given there are the following products | name | unit price | | Flipchart | 250 | | Sticky Notes | 18 | And the is an order with | product | quantity | | Flipchart | 13 | Given the is an order with | product | quantity | | Flipchart | 13 | Flipchart and Sticky Notes are always there
- 33. Copyright © Gaspar Nagy Copyright © Gaspar Nagy 7. Workflow steps • The different user or workflow steps might also represent details that are not relevant • Keeping these details in the scenario causes maintainability issues once the workflow changes • It is better to state the intentions and the relevant steps only • Push down: • Express intention revealing steps and ensure the state by repaying the necessary steps or by applying a shortcut in the automation code Given the customer has logged in And the customer dismissed the newsletter subscription And the customer started to create an order And the customer added the line to the order | product | quantity | | Flipchart | 13 | And the customer has placed the order Given the customer has placed an order with | product | quantity | | Flipchart | 13 | removed non- relevant workflow steps
- 34. Copyright © Gaspar Nagy Wrap-up
- 35. Copyright © Gaspar Nagy Copyright © Gaspar Nagy We covered… • That scenarios need details for execution, but you don’t necessarily need to store those in the scenario itself, but push down to automation code • That in order to use scenarios as specification, we need to make them focused and express only essential details in the steps • That there are different detail types, watch for them and apply the mentioned “push-down” strategies if required
- 36. Copyright © Gaspar Nagy Copyright © Gaspar Nagy Be aware of the details Push them down Make a team agreement on implicit details
- 37. Gáspár Nagy coach • trainer • bdd addict • creator of specflow “The BDD Books” series • https://bddbooks.com @gasparnagy • gaspar@specsolutions.eu Thank you!