1. HOW AND WHY TO LOVE CUCUMBER By Dana Scheider

2. Is This Your Programming Experience?

3. The RSpec Book The whole first part of The RSpec Book is about Cucumber.

4. Behavior-driven development is important and Cucumber is an excellent tool for the job. Thesis

5. Why I’m Here  Software testing is fun!  Cucumber is really fun!  Many people don’t grok Cucumber’s use cases  I’m tired of the way you roll your eyes at me when I tell you I use and contribute to Cucumber

7. Outline  What is (and isn’t) Cucumber?  Cucumber and behavior-driven development  Why some developers don’t like Cucumber  How to love Cucumber

8. I. What Cucumber Is II. Illustrations III. What Cucumber Isn’t What Is Cucumber?

9.  Acceptance testing tool  Composed of “features” and “scenarios” written in Gherkin DSL, and “step definitions” written in Cucumber step definition DSL  Understandable to nontechnical team members  Creates documentation as you write your tests

10. Every Cucumber feature has one or more scenarios, which highlight different use cases, types of input, application states, etc. State is maintained within each scenario, and individual steps, beginning with ‘Given’, ‘When’, ‘Then’, and ‘And’ keywords, run in the context created by previous steps in the same scenario. Gherkin Example

11. Each step has a step definition that either (A) defines changes in the environment, (B) triggers UI events, or (C) sets an expectation using the RSpec expectations API. If the change in the environment/context cannot be made, the UI event cannot be effected, or the expectation is not met, any scenario containing that step fails. Cucumber Step Definition Example

12. What Isn’t Cucumber?  Unit testing tool  Replacement for unit testing  Low-level  Stateless

13. I. What Is BDD? II. Why BDD? III. What is Integration Testing? IV. Example with Cucumber & Rspec Cucumber and BDD

14. What Is BDD?  Focused on API the user uses  Combines unit and integration/acceptance testing  Tests are written first  Minimal planning up front

15. The BDD/TDD Cycle

16. Why BDD?  You need to know what your software does  Users need to know your software works as advertised  Testing enables you to take more risks in the development process  Reduces technical debt  If the code isn’t important enough to test, is it important enough to deploy or deliver to clients?

17. What Is Acceptance Testing?  High level  Not concerned with details of implementation  Mimics how actual users use the software  Covers as much of the API as possible

18. Relationship to Unit Testing  Covers the program as a whole  Tests from the user’s perspective  Not concerned with implementation  Covers specific parts of the program  Tests things the user can’t see  Concerned with how individual parts of the code work & interact Acceptance TestingUnit Testing

19. Each system needs multiple integration/acceptance tests covering user-facing functionality. As that functionality is developed, unit tests are added to test implementation-specific elements that are needed to support the API. Software Suite Structure

20. Unit testing and integration testing have a both/and, not either/or, relationship Relationship to Unit Testing

21. Cucumber and BDD  Use Cucumber for acceptance/integration tests only  Cucumber features determine what unit tests are needed  If unit tests pass, Cucumber features should pass, too  If unit tests fail, Cucumber features should fail, too  Cucumber provides direction for behavior-driven workflows

22. I. Things about testing/TDD/BDD II. Things about Cucumber III. Things about developers Why Some Devs Don’t Like It

23. Things about TDD/BDD  Takes more time before you start coding  Makes you look at software from user’s POV  Can be daunting to break a complex problem down into the smallest possible part  Feels unnecessary, especially at first

24. Things about Cucumber  Uses regular expressions*  Natural language can seem needlessly clunky  Tests can take a longer time than with other frameworks  Can be hard to organize feature and step- definition files * You can use strings instead if you REALLY hate the regular expressions

25. Things about Developers  Already using testing tools that work better for them  Trying to use Cucumber for unit tests  Not taking advantage of the tools in Cucumber’s rich ecosystem  Unable to articulate in plain, natural, language what their software does  Reluctant to bring nontechnical team members and stakeholders into the fold

26. I. Conceptualizing Cucumber II. Contextualizing Cucumber III. Adopting Effective Workflows IV. Organizing Your Features V. Taking Advantage of the Ecosystem How to Love Cucumber

27. Conceptualizing Cucumber  Cucumber is for integration testing  Use Cucumber to write documentation and ensure your software adheres to it  Use your imagination to see your software from the perspective of your eventual user  Explain your use cases and break the explanations down into Cucumber steps

28. Conceptualizing Cucumber

29. Contextualizing Cucumber  Don’t stop unit testing!  Let Cucumber features guide development process  Take advantage of Cucumber’s ability to maintain state between steps  Remember Cucumber is about the user, not the dev  Use Cucumber’s natural-language style to reach consensus with nontechnical stakeholders about specs and deliverables

30. Adopting Effective Workflows  Write Cucumber features before writing unit tests  Discuss Cucumber features with nontechnical team members or stakeholders before writing unit tests  If unit tests pass and features fail, write more unit tests  If unit tests fail and features pass, consider refactoring to remove redundant or unneeded code  Refactor liberally  Use continuous integration/delivery!

31. I. Summary I. TDD/BDD is cool! II. Cucumber’s pretty cool too! II. Questions? Conclusion

32. What TDD & Cucumber Can Bring to Your Projects  Better code quality  Less code  Less technical debt  Built-in documentation known to be accurate  Knowledge about what your app brings to users, in language users can understand  Easy communication with nontechnical people  Fun and happiness!

33. E-mail: dana.scheider@gmail.com Github: danascheider Twitter: @danascheider Dana Scheider