CS 169 Software Engineering
CS 169
Software Engineering"
Armando Fox and David Patterson"
© 2013 Armando Fox & David Patterson, all rights reserved
1"
Outline"
§ 7.9 Explicit vs. Implicit and Imperative vs.
Declarative Scenarios"
§ 7.10-7.12 Fallacies & Pitfalls, BDD Pros & Cons
2"
Explicit vs. Implicit
and Imperative vs.
Declarative
Scenarios (Engineering Software
as a Service §7.9)"
David Patterson"
© 2013 Armando Fox & David Patterson, all rights reserved
3"
Types of Scenarios"
• Are all requirements directly from the User
Stories?"
• Scenarios should have 3 to 8 steps; is there
a way to keep them closer to 3 than to 8?"
4"
Explicit vs. Implicit Scenarios"
• Explicit requirements usually part of
acceptance tests "
– Likely explicit user stories and scenarios: list movies"
• Implicit requirements are logical
consequence of explicit requirements,
typically integration testing"
– Movies listed in chronological order or
alphabetical order?"
5"
Imperative vs. Declarative
Scenarios"
• Imperative: Initial user stories with many
steps, specifying logical sequence to
desired result"
– Not-DRY if many user stories imperative"
• Declarative: describe state, not sequence "
– Fewer steps"
• Example Feature: movies should appear in
alphabetical order, not added order"
• Example Scenario: view movie list after
adding 2 movies "
6"
Example Imperative Scenario"
Given I am on the
Create New Movie page!
RottenPotatoes home page!
When I fill in "Title" with
When I follow "Add new
"Apocalypse Now"!
movie"!
And I select "R" from
Then I should be on the
"Rating"!
Create New Movie page!
And I press "Save Changes"!
When I fill in "Title" with Then I should be on the
"Zorro"!
RottenPotatoes home page!
And I select "PG" from
When I follow ”Movie Title"!
"Rating"!
Then I should see
And I press "Save Changes"!
"Apocalypse Now" before
Then I should be on the
"Zorro"!
RottenPotatoes home page!
Only step specifying behavior;
When I follow "Add new
Rest are implementation. But
movie"!
BDD specifies behavior,
7"
not implementation!
Then I should be on the
Domain Language"
•
•
•
•
Declarative as if making domain language"
Uses terms and concept of app"
Informal language"
Declarative steps describe the state app
should be in "
– Imperative: sequence of steps to change current
state into desired state"
8"
Example Declarative Scenario"
Feature: movies when added
should appear in movie
list!
Scenario: view movie list
after adding movie
(declarative and DRY)!
!Given I have added
"Zorro" with rating
"PG-13"!
!And
I have added
"Apocalypse Now" with
rating "R"!
!Then I should see
"Apocalypse Now" before
"Zorro" on the Rotten
Potatoes home page!
3 steps vs. 15 steps:
2 to set up test,
1 for behavior
Declarative scenarios focus
attention on feature being
described and tested vs.
steps needed to set up test
What about new step
definitions?
9"
Declarative Scenario Needs New Step Definitions"
Given /I have added "(.*)" Then /I should see "(.*)"
with rating "(.*)"/ do |
before "(.*)" on (.*)/ do
title, rating|!
|string1, string2, path|!
Given I am on the Create
step “I am on #{path}"!
New Movie page!
regexp = /
When I fill in "Title"
#{string1}.*#{string2}/m
with "#{title}”!
# /m means match across
newlines!
And I select "#{rating}"
from "Rating"!
page.body.should =~
regexp!
And I press "Save
end!
Changes"!
end!
• As app evolves, reuse steps from first few imperative scenarios
to create more concise and descriptive declarative scenarios
10"
Which is TRUE about implicit vs. explicit
and declarative vs. imperative scenarios?
Explicit requirements are usually defined with
imperative scenarios and implicit requirements
are usually defined with declarative scenarios
2. Explicit scenarios usually capture integration
tests
3. Declarative scenarios aim to capture
implementation as well as behavior
4. All are false.
1.
11"
Fallacies & Pitfalls,
BDD Pros & Cons,
End of Chapter 7 (Engineering Software as
a Service §7.10-§7.12)"
David Patterson"
© 2013 Armando Fox & David Patterson, all rights reserved
12"
Pitfalls"
• Customers confuse digital mock-ups with
completed features"
– Nontechnical customers think highly polished
digital mock-up = working feature"
• Use Lo-Fi mockups, as clearly
representations of proposed feature"
13"
Pitfalls"
• Sketches without storyboards"
– Need to reach agreement with customer on
interaction with pages as well as page content"
• Storyboards / “animating” sketches reduces
misunderstandings"
14"
Pitfalls"
• Adding cool features that do not make the
product more successful"
– Customers reject what programmers liked"
• Trying to predict what code you need before
need it"
– BDD: write tests before you write code you
need, then write code needed to pass the tests"
• User stories help prioritize & BDD minimizes
what you code => reduce wasted effort"
15"
Pitfalls"
• Delivering a story as “done” when only the
happy path is tested"
– Need to test both happy path and sad path"
• Correct app behavior when user accidentally does wrong thing is just as important as correct behavior when does right thing"
– To err is human"
16"
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 …”"
17"
Pitfalls"
• Careless use of positive expectations"
– Then I should see “Emma” what if string appears multiple times on page?"
– Can pass even if feature not working"
• Use Capybara’s within helper"
– Constrains scope of matchers in a CSS selector"
– Then I should see “Emma” within
“div#shopping_cart”!
– See Capybara documentation"
18"
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
4. None
are false; all three above are true
19"
© Copyright 2024