1. Behavioral Driven Development (BDD) (Engineering Software as a Service §7)
Philip Ritchey
slides generously gifted by Jeff Huang

2. Why Do SW Projects Fail? Don’t do what customers want
Or projects are late
Or over budget
Or hard to maintain and evolve
Or all of the above
How does Agile try to avoid failure?

3. My Zune is a Brick 12/31/2008 Midnight
year = ORIGINYEAR; /* = 1980 */ while (days > 365) { if (IsLeapYear(year)) if (days > 366) days -= 366; year += 1; } else days -= 365;
Midnight, New Year’s, 2009, Zune bricked due to leap year bug, reboot after noon on 1/1/2009, everything good.
Microsoft Zune 30 into a brick on New Years' Eve of 2008
12/31/2008
Midnight

4. Agile Lifecycle Review
Work closely, continuously with stakeholders to develop requirements, tests
Users, customers, developers, maintenance programmers, operators, project managers, …
Maintain working prototype while deploying new features every iteration
Typically every 1 or 2 weeks
Instead of 5 major phases, each months long
Check with stakeholders on what’s next, to validate building right thing (vs. verify)

5. BDD+TDD: The Big Picture
Behavior-Driven Design (BDD)
develop user stories (the features you wish you had) to describe how app will work
via Cucumber, user stories become acceptance tests and integration tests
Test-Driven Development (TDD)
step definitions for a new story, may require new code to be written
TDD says: write unit & functional tests for that code first, before the code itself
that is: write tests for the code you wish you had

6. Introduction to Behavior-Driven Design and User Stories (Engineering Software as a Service §7.1)

7. Behavior-Driven Design (BDD)
BDD asks questions about behavior of app before and during development to reduce miscommunication
Validation vs. Verification
Requirements written down as user stories
Lightweight descriptions of how app used
BDD concentrates on behavior of app vs. implementation of app
Test Driven Design or TDD (future segments) tests implementation

8. User Stories 1-3 sentences in everyday language “Connextra” format:
Fits on 3” x 5” index card
Written by/with customer
“Connextra” format:
Feature name
As a [kind of stakeholder], So that [I can achieve some goal], I want to [do some task]
3 phrases must be there, can be in any order
Idea: user story can be formulated as acceptance test before code is written
Dave Patterson created this image
Ideas from CHI community

9. Why 3x5 Cards? (from User Interface community)
Nonthreatening => all stakeholders participate in brainstorming
Easy to rearrange => all stakeholders participate in prioritization
Since stories must be short, easy to change during development
Often get new insights during development

10. Creating User Stories
How do you know if you have a good user story vs. bad user story?
Right size?
Not too hard?
Is worthwhile?

11. SMART User Stories (Engineering Software as a Service §7.3)

12. SMART Stories Specific Measurable
Achievable (ideally, implement in 1 iteration)
Relevant (“the 5 why’s”)
Timeboxed (know when to give up)

13. Specific & Measurable Each scenario testable
Implies known good input and expected results exist
Anti-example: “UI should be user-friendly”
Example: Given/When/Then
Given some specific starting condition(s),
When I do X,
Then one or more specific thing(s) should happen

14. Achievable Complete in 1 iteration
If can’t deliver feature in 1 iteration, deliver subset of stories
Always aim for working end of iteration
If <1 story per iteration, need to improve point estimation per story

15. Relevant: “Business Value”
Discover business value, or kill the story:
Protect revenue
Increase revenue
Manage cost
Increase brand value
Making the product remarkable
Providing more value to your customers

16. 5 Whys to Find Relevance Show patron’s Facebook friends
As a box office manager
So that I can induce a patron to buy a ticket
I want to show her which Facebook friends are going to a given show
Why?
Why add the Facebook feature? As box office manager, I think more people will go with friends and enjoy the show more.
Why does it matter if they enjoy the show more? I think we will sell more tickets.
Why do you want to sell more tickets? Because then the theater makes more money.
Why does theater want to make more money? We want to make more money so that we don’t go out of business.
Why does it matter that theater is in business next year? If not, I have no job.

17. Timeboxed Stop story when exceed time budget
Give up or divide into smaller stories or reschedule what is left undone
To avoid underestimating length of project
Pivotal Tracker tracks velocity, helps avoid underestimate

18. Which feature below is LEAST SMART?
User can search for a movie by title 1. 2.
Rotten Potatoes should have good response time 3.
When adding a movie, 99% of Add Movie pages should appear within 3 seconds
1. Covers all of SMART aspects.
2. Least SMART, no quantitative metric, e.g. response time < 3 seconds
3. Covers all of SMART aspects.
4. Covers all of SMART aspects.
As a customer, I want to see the top 10 movies sold, listed by price, so that I can buy the cheapest ones first 4.

19. Product Backlog Real systems have 100s of user stories
Backlog: User Stories not yet completed
(We’ll see Backlog again with Pivotal Tracker)
Prioritize so most valuable items highest
Organize so they match SW releases over time

20. Which expression statement regarding BDD and user stories is FALSE?
BDD is designed to help with validation (build the right thing) in addition to verification 1. 2.
BDD should test app implementation 3.
User stories in BDD play same role as design requirements in Plan-and-Document
1. True. We will turn behaviors into acceptance tests.
2. False. BDD tests system behavior, not implementation.
3. True. User stories are the BDD requirements.
4. True. It includes the stakeholder, goal and task. 4.
This is a valid User Story: “Search TMDb
I want to search TMDb As a movie fan So that I can more easily find info”

21. Lo-Fi UI Sketches and Storyboards (Engineering Software as a Service §7.4)

22. Building Successful UI
SaaS app often faces users
User stories need User Interface (UI)
How to get customer to participate in UI design so is happy when complete?
Avoid WISBNWIW* UI
UI version of 3x5 cards?
How to show UI interactivity without building a prototype?
*What-I-Said-But-Not-What-I-Want

23. SaaS User Interface Design
UI Sketches: pen and paper drawings or “Lo-Fi UI”

24. Lo-Fi UI Example
(Figure 7.3, Engineering Long Lasting Software by Armando Fox and David Patterson, 1st edition, 2014.)

25. Storyboards Need to show how UI changes based on user actions
HCI => “storyboards”
Like scenes in a movie
But not linear

26. Example Storyboard
(Figure 7.4, Engineering Long Lasting Software by Armando Fox and David Patterson, 1st edition, 2014.)

27. Lo-Fi to HTML
Tedious to do sketches and storyboards, but easier than producing HTML!
Also less intimidating to nontechnical stakeholders => More likely to suggest changes to UI if not code behind it
More likely to be happy with ultimate UI
Next steps: CSS (Cascading Style Sheets) and Haml/Erb
Make it pretty after it works

28. Which is FALSE about Lo-Fi UI?
Like 3x5 cards, sketches and storyboards are more likely to involve all stakeholders vs. code ☐
The purpose of the Lo-Fi UI approach is to debug the UI before you program it ☐
SaaS apps usually have user interfaces associated with the user stories ☐
1. True. Easy to change, so more people willing to give inputs.
2. True. Get all of the views, view elements and view relationships correct before coding.
3. True. A user story talks about interacting with the system, therefore there must be a UI.
4. False. Lo-Fi takes less time than building a prototype.
While it takes more time than building a prototype UI in CSS and Haml, the Lo-Fi approach is more likely to lead to a UI that customers like ☐

29. Productivity and Tools
Don’t we want to avoid major planning effort in Agile? If so, how to estimate time without a plan?
Can User Stories be used to measure progress on project?
What should a tool do to help measure progress for Agile?

30. Points, Velocity, and Pivotal Tracker (Engineering Software as a Service §7.2)

31. Measuring Productivity
A measure of team productivity: calculate avg. no. stories / week?
But some stories much harder than others
Rate each user story in advance on a simple integer scale
1 for straightforward, 2 for medium, 3 for very complex
Velocity: avg. number of points / week
Start with this 3 point scale
Why good idea?
See what you actually accomplish in points per week vs. what you guess as optimistic programmers
Teams learns to get estimate difficulty of user story (gave a story 1 point but took 2 weeks; why was it hard? Learn from mistakes)

32. More on Points
Once get experience, Fibonnaci scale is commonly used: 1, 2, 3, 5, 8
(Each new number is sum of previous 2)
At Pivotal Labs, 8 is extremely rare
Teams assign value: vote by holding up fingers simultaneously, take average
If a big disagreement (2 and 5), discuss more
How decide points – rock, paper, scissors – everyone says how many points a story is, and see if agree
Go with average, but record each opinions, check later to see how well you did, why are some team members more accurate estimators?

33. More on Points ≥5 => divide user story into simpler stories
backlog not too demanding
Doesn’t matter if velocity is 5 or 10 points per iteration
As long as team is consistent
Idea is to improve self-evaluation and suggest number of iterations for feature set
At Pivotal Labs, break into multiple stories
Every time there is a SW concept, someone builds a tool to implement idea to make it easy to do

34. Pivotal Tracker
Calculates velocity for team, manages user stories: Current, Backlog, Icebox
Pivotal Labs brought us Pivotal Tracker
Bookkeeping for user stories, as long as doing that, might as well calculate velocity Upper right corner is team velocity (10 in this case)
Very easy to use
Current
Done
Backlog (not shown) – what work on next
Icebox – invent more stories than will ever implement (frozen)
Pivotal will move things from backlog to current automatically and assign people to the tasks
Top to bottom is prioritized order (except in icebox, it is random)

35. Pivotal Tracker
Prioritize user stories by where place them in Current, Backlog, Icebox panels
When completed, move to Done panel
Can add logical Release points, so can figure out when a Release will really happen
Remaining points/Velocity
Epic: give software engineers the big picture of where the application is in the development process with regard to big feature
Will put into backlog with Release Point
Tracker will estimate when Release Point looks to be
Tell customer as go along

36. Tracker Roles Developers don’t decide when user stories completed
Pushes Finish button, which sends to “Product Owner” (as in Scrum team organization)
Product Owner tries out the user story and then either hits “Accept” or “Reject”
Accept, which marks user story as done, or
Reject, which marks story as needing to be Restarted by developer
Follow scrum roles, Product owner signs off

37. Pivotal Tracker: Features vs. Chores
User stories that provide verifiable business value to customer
“Add agree box to checkout page”
Worth points & therefore must be estimated
Chores
User Stories that are necessary, but provide no direct, obvious value to customer
“Find out why test suite is so slow”
No points

38. Which expression statement regarding Points, Velocity, and Tracker is TRUE?
When comparing two teams, the one with the higher velocity is more productive 1. 2.
When you don’t know how to approach a given user story, just give it 3 points 3.
With Tracker, developers pick the user stories and mark as Accepted when done
1. False. Since each team assigns points to user stories, you cannot use velocity to compare different teams. However, you could look at a given team over time to see if there were some iterations that were significantly less or more productive
2. False. User stories should not be so complex that you don’t know have an approach to implementing it. If they are, you should go back to your stakeholders to refactor the user story into a set of simpler tasks that you do know how to approach
3. False. Product owners say when done, not developers
4. True.
Velocity is self-assessment
Not supposed to not know what you’re doing
Tracker helps prioritize and keep track of user stories and their status, calculates velocity, and predicts software development time 4.

39. GitHub Issues & Pivotal Tracker
Bug tracking vs Project management
Integration:

40. Alternatives Trello https://trello.com/ Waffle https://waffle.io/
It’s Free!
Simple, clean UI
Waffle

41. User Stories => Acceptance Tests?
Wouldn’t it be great to automatically map 3x5 card user stories into tests for user to decide if accept the app?
How would you match the English text to test code?
How could you run the tests without a human in the loop to perform the actions?
Need to map from user stories to acceptance tests for test-driven design

42. Introducing Cucumber & Capybara (Engineering Software as a Service §7

43. Cucumber & RSpec
Cucumber describes behavior via features & scenarios (behavior driven design)
RSpec tests individual modules that contribute to those behaviors (test driven development)
Failing (red) Cucumber step
Failing (red) RSpec test
Passing (green) RSpec test
1st step is thinking of “code you wish you had”, assuming methods that if existed would make it a perfect match to the user story.
Rather than inside – out (start with building blocks and compose to provide desired functionality), go from users outside-in, to reduce wasted coding; e.g., until get to user view, won’t know what you really need. Especially Web apps, since easy to see what the user is doing.
Both cycles involve taking small steps and listening to the feedback
you get from the tools. We start with a failing step (red) in Cucumber
(the outer cycle). To get that step to pass, we’ll drop down to RSpec
(the inner cycle) and drive out the underlying code at a granular level
(red/green/refactor).
At each green point in the RSpec cycle, we’ll check the Cucumber cycle.
If it is still red, the resulting feedback should guide us to the next action in the RSpec cycle.
If it is green, we can jump out to Cucumber, refactor
if appropriate, and then repeat the cycle by writing a new failing
Cucumber step.
Passing (green) Cucumber step

44. Cucumber: Big Idea Tests from customer-friendly user stories
Acceptance: ensure satisfied customer
Integration: ensure interfaces between modules consistent assumptions, communicate correctly
Cucumber meets halfway between customer and developer
User stories are not code, so clear to customer and can be used to reach agreement
Also not completely freeform, so can connect to real tests

45. Example User Story 1 Feature ≥1 Scenarios / Feature
Feature: User can manually add movie Scenario: Add a movie Given I am on the RottenPotatoes home page When I follow "Add new movie" Then I should be on the Create New Movie page When I fill in "Title" with "Men In Black" And I select "PG-13" from "Rating" And I press "Save Changes" Then I should be on the RottenPotatoes home page And I should see "Men In Black"
1 Feature
≥1 Scenarios / Feature
3 to 8 Steps / Scenario
Note that mapping from 3x5 cards to Cucumber can be erroneous, ultimately need user to test.
This scenario assumes I can leave the movie date blank.

46. Cucumber User Story, Feature, and Steps
User story: refers to single feature
Feature: ≥1 scenarios that show different ways a feature is used
Keywords Feature and Scenario identify respective components
Kept in .feature files
Scenario: steps that describe scenario
Step definitions: Ruby code to test steps
Kept in X_steps.rb files

47. 5 Step Keywords
Given steps represent state of world before event: preconditions
When steps represent event
e.g., simulate user pushing a button
Then steps represent expected postconditions; check if true
/ 5. And & But extend previous step

48. Steps => Step Definitions via Regular Expressions
Regexes match English phrases in steps of scenarios to step definitions!
Given /^(?:|I )am on (.+)$/
“I am on the Rotten Potatoes home page”
Step definitions (Ruby code) likely use captured string
“Rotten Potatoes home page”
(?: re) Groups regular expressions without remembering matched text.
(?:|I ) will match “I “ and throw it away or match nothing, so strings starting with “I am on ...” will match, and so will “am on …” will match as well.

49. Red-Yellow-Green Analysis
Cucumber colors steps
Green for passing
Yellow for not yet implemented
Red for failing (then following steps are Blue)
Goal: Make all steps green for pass
(Hence green vegetable for name of tool)

50. The BDD Cycle in Rails

51. More on “Cuke” Need to install Cucumber Gem
Just for test and development environment, not for production environment
When Cucumber installed, it creates commonly used step definitions
Need a test database to run app
Then edit .features file to add features

52. Fake User to Try Scenarios?
Need tool that pretends to be the user to follow scenarios of user stories
Capybara simulates browser
Can interact with app to receive pages
Parse the HTML
Submit forms as a user would
Capybara – rat the size of a dog, largest rodent in the world, native to South America
Webrat used to be tool for Ruby acceptance testing for web applications

53. Which is FALSE about Cucumber and Capybara?1.
Step definitions are in Ruby, and are similar to method calls, while steps are in English and are similar to method definitions 2.
A Feature has one or more Scenarios, which are composed typically of 3 to 8 Steps
Steps use Given for current state, When for actions, and Then for consequences of actions 3.
False. Step definitions are like method definitions, and steps are like method calls.
True.
Cucumber matches step definitions to scenario steps using regexes, and Capybara pretends to be a user that interacts with the SaaS app accordingly 4.

54. Enhancing Rotten Potatoes Again (Engineering Software as a Service §7
Start at 3:00, end at 9:00, so takes 6 minutes

55. Add a Real New Feature? What if we add something harder?
e.g., includes form to fill in
e.g., needs a User Interface
e.g., needs to add route to connect view to controller
e.g., includes both a happy path and a sad path

56. Integrated with The Movie Database (TMDb)
New Feature: Populate from TMDb, versus enter information by hand
Need to add ability to search TMDb from Rotten Potatoes home page
Need LoFi UI and Storyboard

57. Storyboard TMDb Figure 7.6 of Engineering Software as a Service
The home page of Rotten Potatoes, which lists all movies, will be augmented with a search box where we can type some title keywords of a movie and a “Search” button that will search TMDb for a movie whose title contains those keywords.
If the search does match—the so-called “happy path” of execution—the first movie that matches will be used to “pre-populate” the fields in the Add New Movie page that we already developed
If the search doesn’t match any movies—the “sad path”—we should be returned to the home page with a message informing us of this fact.
Easy Story Board

58. Search TMDb User Story (Fig. 7.7 ESAAS)
Feature: User can add movie by searching in The Movie Database (TMDb) As a movie fan So that I can add new movies without manual tedium I want to add movies by looking up their details in TMDb Scenario: Try to add nonexistent movie (sad path) Given I am on the RottenPotatoes home page Then I should see "Search TMDb for a movie" When I fill in "Search Terms" with "Movie That Does Not Exist" And I press "Search TMDb" Then I should be on the RottenPotatoes home page And I should see "'Movie That Does Not Exist' was not found in TMDb."
Usually start with happy path; but we’d have to implement method for searching and matching TMDb, which we’ll do in next chapter.
(Have to explain both BDD and TDD, so we’ll do BDD first – so don’t do sad path)
Instead, do a sad path where can’t find it, and put in dummy method that always fails to find, which makes sad path work.
BDD next will go further in TDD to build the method you need. Not a good idea, but works for this chapter. In future, will go back and forth between BDD design and TDD implementation

59. Haml for Search TMDb Page (Fig. 7.8 ESAAS)
-# add to end of app/views/movies/index.html.haml: %h1 Search TMDb for a movie = form_tag :action => 'search_tmdb' do %label{:for => 'search_terms'} Search Terms = text_field_tag 'search_terms' = submit_tag 'Search TMDb'
We will need a new view to go with new UI, and then include a form to fill in
Haml – more concise version of Markup Language than HTML,
1st line is search movie. Need to make a name for the action, we’ll call it “search_tmdb”
Label is form where fill in the information for movie when it does match
Line 3: %h1 Search TMDb for a movie
is the text that allows Then I should see “Search TMDb for a movie” to pass.
As with any user interaction in a view, we need a controller action that will handle that Web interaction. In this case the interaction is submitting the form with search keywords.
Line 5 = form_tag :action => 'search_tmdb' do
says that when the form is submitted, the controller action search_tmdb will receive the form submission.

60. Try Cucumber? If try Cucumber, it fails Missing the route
Also MoviesController#search_tmdb is controller action that should receive form, yet not in movies_controller.rb
Should use Test Driven Development to implement method search_tmdb
Instead, to finish sad path, add fake controller method that always fails

61. Demo Add feature to search for movie in TMDb
Note: This will be a sad path, in that won’t find it
Will use fake method (until future when implement it using TDD)
(Or can look at screencast:
When adding a feature, usually need to write new UI, new step definitions, and new controller method.
Be sure to save edits. Use tabs from pastebin
First step OK, since on RP page
{Then I should see ``Search TMDb for a movie'’} should fail (red), because we haven't yet added this text to the home page
Try to run cuke on new feature: cucumber features/search_tmdb.feature
Says 1 passed, rest failed
2. In book says to fix that view, need to copy code from Figure 7.7, which is in PasteBin.
It modifies app/views/movies/index.html.haml.
If use vi, be sure to put in paste mode - :set paste (:set nopaste changes mode)
Try to run cuke
Now complains no route
3. In book says to fix route, need to copy code from Figure 7.9 (top). It modifes config/routes.rb
4. We will also set dummy controller method now from Figure 7.9 (bottom). It modifies app/controllers/movies_controller.rb
Try to run cuke, all steps green

62. Trigger Fake Controller When Form is POSTed (Fig. 7.9)
# add to routes.rb, just before or just after 'resources :movies' : # Route that posts 'Search TMDb' form post '/movies/search_tmdb'
we have to make sure there is a route to this new controller action.
Above is the line you must add to config/ routes.rb to add a form submission (POST) route to that action

63. Fake Controller Method: Will Fail Finding Movie (Fig. 7.9)
# add to movies_controller.rb, anywhere inside # 'class MoviesController < ApplicationController': def search_tmdb # hardwired to simulate failure flash[:warning] = "'#{params[:search_terms]}' was not found in TMDb." redirect_to movies_path end
For now, use fix It to fail, which let’s us complete the sad path. This “fake” controller method always behaves as if no matches were found. It retrieves the keywords typed by the user from the params hash (as we saw in Chapter 3), stores a message in the flash[], and redirects the user back to the list of movies. Recall from Chapter 3 that we added code to app/views/layouts/application.html.haml to display the contents of the flash on every view.

64. Happy Path of TMDb
Find an existing movie, should return to Rotten Potatoes home page
But some steps same on sad path and happy path
How to make it DRY?
Background means steps performed before each scenario

65. TMDb w/2 Scenarios: Background (Fig. 7.10)
Feature: User can add movie by searching for it in The Movie Database (TMDb) As a movie fan So that I can add new movies without manual tedium I want to add movies by looking up their details in TMDb Background: Start from the Search form on the home page Given I am on the RottenPotatoes home page Then I should see "Search TMDb for a movie” Scenario: Try to add nonexistent movie (sad path) When I fill in "Search Terms" with "Movie That Does Not Exist" And I press "Search TMDb" Then I should be on the RottenPotatoes home page And I should see "'Movie That Does Not Exist' was not found in TMDb.” Scenario: Try to add existing movie (happy path) When I fill in "Search Terms" with "Inception" And I should see "Inception”

66. Cucumber Summary
New feature => UI for feature, write new step definitions, even write new methods before Cucumber can color steps green
Both happy and sad paths (don’t forget the sad paths!)
Background lets us DRY out scenarios of same feature
BDD/Cucumber test behavior; TDD/Rspec later is how write methods to make all scenarios pass

67. And in Conclusion
Cucumber – “magically” maps 3x5 card user stories onto acceptance tests and integration tests for the application

68. Pitfalls Careless use of negative expectations
Beware of overusing “Then I should not see….”
Can’t tell if output is what want, only that it is not what you want
Many, many outputs are incorrect
Include positives to check results “Then I should see …”

69. BDD Good & Bad
User stories - common language for all stakeholders, including nontechnical
3x5 cards
LoFi UI sketches and storyboards
Write tests before coding
Validation by testing vs. debugging
Difficult to have continuous contact with customer?
Leads to bad software architecture?
Will cover design patterns, refactoring in future
Kent Beck (Mr. XP) said it WILL have bad architecture – will see refactoring and design patterns later

70. BDD Doesn’t feel natural at first
Rails tools make it easier to follow BDD
Once learned BDD and had success at it, no turning back
2/3 Alumni said BDD/TDD useful in industry
SW Engineering invented because good programming is unnatural

71. Which statement is FALSE about Lo-FI UI and BDD?1.
The purpose of the Lo-Fi UI approach is to debug the UI before you program it 2.
A BDD downside is requiring continuous contact with customers, which may not be possible 3.
A BDD downside is that it may lead to a poor software architecture, since focus is on behavior
True. Get rough outline for all views and interactions.
True. The user may have new ideas, want to reprioritize stories, etc.
True. It is hard to take a global perspective, since you are implementing stories one at a time. Have to refactor later.
True.
None are false; all three above are true 4.