Journey of atdd
0 likes1,174 views
This document discusses Acceptance Test Driven Development (ATDD). It begins by explaining that ATDD focuses on communication, collaboration, and building automated acceptance criteria to develop the right product. It then contrasts ATDD with traditional Test Driven Development, noting that while TDD ensures the code is developed correctly, ATDD ensures the correct product is developed. The document concludes by demonstrating ATDD in action using Cucumber, and discusses some challenges and anti-patterns of adopting ATDD.
Journey of atdd
- 1. JOURNEY OF ACCEPTANCE TEST DRIVEN DEVELOPMENT “Begin with the end in mind.” — Stephen R. Covey
- 2. About the speakers Devesh Maheshwari Blog: http://www.devmaheshwari.wordpress.com Twitter: @demahesh Priyank Dhillon Blog: http://priyankdhillon.wordpress.com/ Twitter: @priyankdhillon 2
- 3. Agenda 3 What is Acceptance Test Driven Development? Where is it applicable How it differs from TDD See ATDD in action(Cucumber and Ruby) Touch point on various BDD tools Anti-patterns & Challenges
- 4. Some reasons why projects fail 4
- 7. Delivering wrong product/feature7 Sales Department Development Team Customer 1. Initial requirements Project was rejected by the customer “Actually, we asked for something different” 2. Adjusted requirements 3. Wrong product
- 9. Unstable 9
- 11. How to target these problems Communication Collaboration Automation Process improvements Shared understanding 11
- 13. TDD … Is a test first approach It leads to think about “How to use a component” than “how to implement” As much about design technique as testing technique. 13
- 14. Quote from Dan North “TDD will cause me to have lots of tests, but it won’t necessarily get me nearer the goal of delivering business value through software” 14
- 15. ATDD is about… 15 Communication Collaboration Automated acceptance criteria Living documentation Shared understanding Process improvements Building the right software 15
- 16. ATDD Cycle 16
- 17. ATDD & TDD go hand in hand 17 TDD helps to develop product right ATDD helps to develop right product
- 18. Shared understanding “Having the conversation is more important than recording the conversation is more important than automating the conversation” – Liz Keogh Source: http://lizkeogh.com/behaviour- driven-development/ 18
- 19. How to build shared understanding Shared understanding Story Examples Automated Acceptance Criteria Working Software and Living documentation 19
- 20. Acceptance Criteria + Examples (data + scenarios) _____________________ Acceptance Tests _____________________ Given some precondition When I do some action Then I expect some result Acceptance Tests 20
- 21. Good Acceptance Tests S – Specific: Explicitly defined and definite M – Measurable: Possible to observe and quantify A – Achievable: Capable of taking place R – Relevant: Having a connection with the story T – Time bound: When will the outcome be observed Rules Focus on “what” you are testing and not on “how” Eliminate irrelevant details Consolidate similar tests with readable tables Use decision tables and boundary analysis to get high coverage 21
- 22. Acceptance Criteria Feature: As a Customer I want to borrow money from the bank So that I can go on Holiday and enjoy myself Acceptance Criteria: In order to get the Holiday Loan approved 1. The Customer must be 18 or older 2. The Customer’s salary must be > $20,000.00 3. The Customer Time in employment must be >= 6 months 4. The Loan amount < (Customer salary)/5 22
- 23. 23
- 24. Step 1 - basic test 24
- 25. Focus on “what” you are testing not on “how” 25
- 27. Cont.. 27
- 28. Consolidate similar tests with readable tables 28
- 29. Scenarios – looking back 29 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
- 30. ToolsFrameworks 30 JDave - http://jdave.org/ Concordion - http://www.concordion.org Easyb - http://easyb.org/ Thucydides- www.thucydides.info Jbehave (Java) - http://jbehave.org/ Cbehave (C) - https://code.google.com/p/cbehave/ Cucumber - http://cukes.info/ Igloo (C++) - http://igloo-testing.org/ Cuke4Nuke SpecFlow Spinach
- 31. Will cucumber test the features? No, not really Parse the gherkin Match gherkin with your test functions Execute the matched test functions Generate a report 31
- 32. Lets see it in action 32
- 33. Benefits 33 Better definition of scope and “done” More scenarios identified upfront Preventing defects is cheaper than fixing them Prevents system regression Same visibility for all roles on the team Provide visibility Living documentation Remove the ambiguity Customer can give you early feedback Customer can read and write some of them
- 34. Challenges in adopting ATDD Works best in an iterative environment 34
- 35. Challenges cont... Writing good scenarios takes practice 35
- 36. Challenges cont... Poorly written tests can lead to higher test maintenance cost. 36
- 37. Challenges cont... Treat test automation code like production code. 37
- 38. Challenges cont... It requires high business engagement and collaboration 38
- 39. Anti patterns The product owner/business analyst writes the scenario and then gives them to the other team members. Scenarios are UI focused and missing context (business value). Testing team writes the scenario at the end to implement an automated test suite. Developers coming up with scenarios without having conversation with the team. 39
- 40. Way for a better specifications 40 Collaborative approach Specify behavior, not implementation Testable requirements Automate specification tests Control specification maintainability
- 41. Other names of ATDD Behavior Driven Development Specification by example Executable specification 41
- 42. 42 ATDD is not just about frameworks It’s about conversation
- 43. Making Hard Decisions Usually early in the project Should I use ATDD at all ? Should I use Gherkin, will I get value out of it ? Should I test UI or only the core ? How much UI should I test ? Will my customer would read the gherkin ? Will my customer be available to participate in conversation ? Is my technical team is the customer ? I would like to change my mind in the future. 43
- 44. Want to learn more Dan North’s blog http://dannorth.net/introducing-bdd/ Elisabeth Hendrickson blog http://testobsessed.com/2008/12/acceptance-test-driven-development-atdd-an-overview BDD in action by John Smart http://www.wakaleo.com http://www.thucydides.info Lisa Crispin and Janet Gregory http://www.agiletester.ca/ Wikipedia http://en.wikipedia.org/wiki/Behavior-driven_development Few other links http://www.extremeprogramming.org http://lostechies.com/derekgreer/author/derekgreer/ http://mysoftwarequality.wordpress.com https://blog.codecentric.de http://mysoftwarequality.wordpress.com/2012/12/14/how-to-transform-bad-acceptance- tests-into-awesome-ones/ https://blog.codecentric.de/en/2013/08/cucumber-setup-basics/ 44
- 45. The End 45