BDD and Acceptance Testing with Cucumber

BDD and Acceptance Testing with Cucumber presentation from Desert Code Camp 2012

Transcript

1. BDD and Acceptance Testing with Cucumber Dave Lesser Desert Code Camp 2012 November 16, 2012
2. About Me ›  PM & Ruby Developer at Unicon ›  @davelesser ›  github.com/davelesser
3. What is Cucumber? ›  A tool for implementing automated acceptance tests written in a behavior- driven development style ›  Describes the desired software behavior in business-readable English ›  Encourages tests to be defined/written by…wait for it…the business (gasp!)
4. Why should you care? ›  “Acceptance tests written in this style become more than just tests; they are executable specifications.”* ›  Provides the business and technical teams with a common language to build/test software ›  Catch missed requirements, defects, and regressions as early as possible *Matt Wynne and Aslak Hellesøy, The Cucumber Book
5. Too much, too soon? We’ll dive into Cucumber one step at a time
6. Background Before we get into Cucumber, it’s worth covering the principles on which it is built
7. What is Acceptance Testing? ›  Automated testing using criteria defined by the business stakeholders ›  “It’s sometimes said that unit tests ensure you build the thing right, while acceptance tests ensure you build the right thing.”* *Matt Wynne and Aslak Hellesøy, The Cucumber Book
8. Goal: Avoid This…
9. Behavior-Driven Development ›  Outside-in testing approach ›  Describes features/behavior from Stakeholders’ POV ›  Keeps focus on the business goals
10. Checkpoint So far so good?
11. Features •  What are they? •  How, when, and by whom are they written? •  Best practices
12. User Stories vs. Features User Stories As a [user/role] I want [feature] So that [benefit] Features Scenario [title] Given [context] When [event] Then [outcome]* (optional) And… But… *Important: Outcome(s) must be testable
13. Gherkin ›  Cucumber’s primary language ›  Supports 40+ human languages ›  Features composed of Scenarios (as chapters are composed of paragraphs) ›  Scenarios composed of Steps (as paragraphs are composed of sentences) ›  Steps matched with executable code
14. Gherkin Example
15. Who and When ›  Ideally, written in conjunction with the business (preferably by the business) ›  Potential authors: ›  Product Owner ›  Business Analyst ›  Quality Assurance ›  Developer/SQE ›  Written as early as possible
16. Best Practices ›  Written like clear/concise documentation (because that’s what it is) ›  Use business language not technical language ›  Features should focus on business value and avoid implementation details
17. Do This ›  High-level ›  Easy to understand what’s being tested ›  Independent of implementation details
18. Don’t Do This ›  No idea what’s going on here ›  Tightly coupled to implementation
19. Checkpoint Still hanging in there?
20. Example: Live Demo ›  Makes an interesting end-of-sprint demo item (at least initially) ›  Show features being executed while audience watches the application being tested
21. Artifacts ›  The features themselves ›  Interactive HTML report ›  Screenshots ›  Console output ›  Email (via CI server or application code) ›  Anything else which can be programmed
22. Sample Report
23. Checkpoint Still awake?
24. Technical Overview •  Step Definitions •  Browser Testing •  Non-Browser Testing •  Automating Cucumber
25. Step by Step ›  Ruby-based but has adaptations in other languages: ›  Java: Cuke4Duke (JRuby), Cucumber-JVM ›  .NET: SpecFlow ›  Python, PHP: Cucumber-ish implementations ›  Step Definitions contain the execution code and the assertions ›  Assertions are usually written in RSpec, but many other methods are supported
26. Browser Testing ›  Personal preference for Watir WebDriver ›  Selenium and Capybara are also popular ›  Supports Firefox, Chrome, IE, and Safari ›  Able to spoof UA and screen resolution to emulate Android and iOS devices (via webdriver-user-agent gem) ›  Use xvfb and headless gem to facilitate running on headless servers
27. Page Object ›  Page Object: a popular pattern to organize UI acceptance tests ›  A page object represents a screen or part of a screen in your web application ›  In this way, UI behavior is kept DRY and easy to find
28. Non-Browser Testing ›  Cucumber can also test: ›  REST/SOAP APIs ›  Desktop applications (GUI, CLI) ›  Android & iOS applications ›  Java, .NET, Python, PHP, Scala, Clojure, Erlang, Lua, and Flash applications
29. Automating Cucumber ›  Can be automated by a CI server, such as Jenkins, via Rake task ›  Runs on whatever schedule makes sense ›  After commits ›  On set schedule ›  After new deploys ›  Can automatically generate/archive reports and notify team of failed tests
30. Checkpoint Still vertical?
31. Resources Helpful links to topics covered in this presentation
32. Presentation Materials ›  Slide deck and sample Cucumber app: ›  https://github.com/davelesser/cucumber- dcc12 ›  Links to slides in README
33. Suggested Reading ›  The Cucumber Book (technical and non- technical audiences) ›  http://pragprog.com/book/hwcuc/the- cucumber-book ›  Cucumber Recipes (technical audience) ›  http://pragprog.com/book/dhwcr/ cucumber-recipes ›  Cucumber ›  http://cukes.info/
34. Libraries and Tools ›  RSpec ›  http://rspec.info ›  Watir WebDriver ›  http://watirwebdriver.com ›  Webdriver::User::Agent ›  https://github.com/alisterscott/webdriver- user-agent
35. Libraries and Tools (cont.) ›  headless ›  http://leonid.shevtsov.me/en/headless ›  page-object ›  https://github.com/cheezy/page-object
36. Questions?