Cucumber: Bridging Communication Gaps with Developers and Stakeholders

Cucumber is a behavior-driven testing framework that allows development teams to describe how software should behave in plain english. Writing features in Cucumber aligns well with Agile and Scrum teams. User stories in Agile or story points in Scrum follow the same plain language rules as Cucumber and can be a large benefit to help improve collaboration between technical and non-technical users. This session will cover:

• how to correctly describe an applications behavior using Cucumber syntax & vocabulary
• writing scenarios, features, and step definitions
• the pitfalls of writing poor Cucumber features
• collaboration benefits between technical and non-technical team members
• 5 quick ideas to help you convince stakeholders to write your features for you

Transcript

1. Cucumber BRIDGING COMMUNICATION GAPS WITH DEVELOPERS AND STAKEHOLDERS @BERMONPAINTER ConFoo 2014
2. The hardest single part of building a software system is deciding precisely what to build. ! - Fred Brooks
4. Overview OUTLINE UNIT TESTS vs. ACCEPTANCE TESTS Workflow FEATURES, SCENARIOS, & STEPS Step Definitions VERIFY ACCEPTANCE CRITERIA Benefits & Best Practices WRITING FEATURES & IMPROVING COLLABORATION Convincing Stakeholders 5 WAYS TO CONVINCE STAKEHOLDERS TO WRITE FEATURES
5. Cucumber BEHAVIOR DRIVEN DEVELOPMENT FRAMEWORK
6. Written in a plain text language called Gherkin. CUCUMBER
7. Describes how software should behave. CUCUMBER
8. Helps bridge gaps in communication with non-technical and technical teams. CUCUMBER
9. Can provide a consistent feedback loop. CUCUMBER
10. Minimizes misunderstandings & incorrect concepts before implementing in code. CUCUMBER
11. Reduces costs, decreases time-to- market and improves maintainability. CUCUMBER
12. Unit Tests UNIT TESTS vs. ! ACCEPTANCE TESTS ENSURE YOU BUILD THE THING RIGHT
13. Unit Tests UNIT TESTS vs. ! ACCEPTANCE TESTS ENSURE YOU BUILD THE THING RIGHT Acceptance Tests ENSURE YOU BUILD THE RIGHT THING
14. Workflow FEATURES, SCENARIOS & STEPS
16. Features WRITTEN BY STAKEHOLDERS IN COLLABORATION WITH THE TEAM
17. Step Definitions WRITTEN BY DEVELOPERS
18. Application WRITTEN BY DEVELOPERS
19. Feature Files DESCRIBE HOW STAKEHOLDERS THINK THE SYSTEM SHOULD WORK
20. FEATURE FILES Feature: Feedback when entering invalid credit card details ! In user testing we've seen a lot of people who made mistakes entering their credit card. We need to be as helpful as possible here to avoid losing users at this crucial stage of the transaction. ! Scenario: Credit card number too short Given I have chosen some items to buy
 And I am about to enter credit card info
 When I enter a card number that's only 15 digits long
 And all the other details are correct
 And I submit the form
 Then the form should be redisplayed
 And I should see a message advising me of the correct number of digits
21. FEATURE FILES Feature: … ! Scenario: … Given: … And: … When: … Then: … And: … Features EACH FEATURE FILE BEGINS WITH A FEATURE IN ORDER TO PROVIDE A DESCRIPTIVE SUMMARY. ! FEATURE DESCRIPTIONS PROVIDE CONTEXT.
22. FEATURE FILES Feature: … ! Scenario: … Given: … And: … When: … Then: … But: … Scenarios SCENARIOS PROVIDE AN EXAMPLE OF HOW THE SYSTEM SHOULD BEHAVE.
23. FEATURE FILES Feature: … ! Scenario: … Given: … And: … When: … Then: … But: … Steps WRITTEN IN PLAIN ENGLISH. STEPS WILL MAKE UP THE MAJORITY OF A FEATURE FILE.
24. FEATURE FILES Feature: … ! Scenario: … Given: … And: … When: … Then: … But: … Steps GIVEN: SETUP
25. FEATURE FILES Feature: … ! Scenario: … Given: … And: … When: … Then: … But: … Steps GIVEN: SETUP ! WHEN: ACTIONS ! THEN: ASSERTIONS
26. FEATURE FILES Feature: … ! Scenario: … Given: … And: … When: … Then: … But: … Steps GIVEN: SETUP ! WHEN: ACTIONS ! THEN: ASSERTIONS ! AND/BUT: HELPERS
27. FEATURE FILES Feature: Feedback when entering invalid credit card details ! In user testing we've seen a lot of people who made mistakes entering their credit card. We need to be as helpful as possible here to avoid losing users at this crucial stage of the transaction. ! Scenario: Credit card number too short Given I have chosen some items to buy
 Given I am about to enter credit card info
 Given I enter a card number that's only 15 digits long
 Given all the other details are correct
 Given I submit the form
 Given the form should be redisplayed
 Given I should see a message advising me of the correct number of digits
28. FEATURE FILES Feature: Feedback when entering invalid credit card details ! In user testing we've seen a lot of people who made mistakes entering their credit card. We need to be as helpful as possible here to avoid losing users at this crucial stage of the transaction. ! Scenario: Credit card number too short * I have chosen some items to buy
 * I am about to enter credit card info
 * I enter a card number that's only 15 digits long
 * all the other details are correct
 * I submit the form
 * the form should be redisplayed
 * I should see a message advising me of the correct number of digits
29. Step Definitions EXECUTE SCENARIOS IN FEATURE FILES AND VERIFY THAT THE SYSTEM MEETS ACCEPTANCE CRITERIA
30. STEP DEFINITIONS Feature: Feedback when entering invalid credit card details ! Given /I have chosen some items to buy/ do
 # CODE GOES HERE end ! When /I enter a card number that's only 15 digits long/ do
 # CODE GOES HERE end ! And /all the other details are correct/ do
 # CODE GOES HERE end ! And /I submit the form/ do
 # CODE GOES HERE end ! Then /the form should be redisplayed/ do
 # CODE GOES HERE end
31. Process PUTTING ALL OF THE PIECES TOGETHER AS A TEAM
32. 1. Describe Behaviors (STAKEHOLDER + TEAM) ! 2. Write Step Definitions (DEVELOPERS) ! 3. Run Tests (TESTS FAIL) ! 4. Write Code for Tests to Pass ! 5. Run Tests (TESTS PASS) FAIL PASS REFACTOR
33. Writing Features BENEFITS & BEST PRACTICES TO GET THE MOST OUT OF CUCUMBER & BDD
34. Improve client & team communication BENEFITS
35. Encourages discussions among all team members BENEFITS
36. Better integration & acceptance testing BENEFITS
37. Describe features, not a sequence of actions BEST PRACTICES
38. Keep features at a high level BEST PRACTICES
39. Hide complexity in the implementation of the steps BEST PRACTICES
40. Test the most important/risky pieces of a system first BEST PRACTICES
41. Write tests until the remaining risk isn't worth the time & money to address BEST PRACTICES
42. Commit Feature Files to Version Control. INSTANT FEATURE HISTORY
43. Improving Collaboration WORKING WITH TO IMPROVE COMMUNICATION WITH STAKEHOLDERS
44. Developers write all feature files UNFORTUNATE COMMON OCCURRENCES
45. Stakeholders write all feature files UNFORTUNATE COMMON OCCURRENCES
46. Stakeholders write feature files in collaboration with their team BEST CASE SCENARIO
47. Convincing Stakeholders 5 WAYS TO CONVINCE STAKEHOLDERS TO WRITE FEATURE FILES
48. Do only as much planning, analysis, and design as you need, but no more. ONE
49. Deliver stakeholder value TWO
50. Create a consistent language THREE
51. Concise and understandable documentation FOUR
52. Explore examples through collaboration FIVE
53. You should not be afraid to delete tests that are no longer providing value, no matter whether you originally planned to keep them or not. We tend to treat tests as these holy creatures that live blameless, irreproachable lives once they have sprung into existence. ! Not so. ! The maintenance required to keep a test running weighs against its value in further development. Sometimes these lines cross, and the test simply becomes a burden on the project. Having the skill and experience to recognize a burdensome test is something we should be bringing to our clients, as well as the fortitude to rewrite it, rethink it, or delete it. ! - Adam Milligan
54. Fin. @BERMONPAINTER ConFoo 2014