Presentation is loading. Please wait.

Presentation is loading. Please wait.

Explicit vs. Implicit and Imperative vs. Declarative Scenarios (Engineering Software as a Service §7.9) 1 © 2013 Armando Fox & David Patterson, all rights.

Similar presentations


Presentation on theme: "Explicit vs. Implicit and Imperative vs. Declarative Scenarios (Engineering Software as a Service §7.9) 1 © 2013 Armando Fox & David Patterson, all rights."— Presentation transcript:

1 Explicit vs. Implicit and Imperative vs. Declarative Scenarios (Engineering Software as a Service §7.9) 1 © 2013 Armando Fox & David Patterson, all rights reserved

2 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? 2

3 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? 3

4 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 4

5 Example Imperative Scenario 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 "Zorro" And I select "PG" from "Rating" And I press "Save Changes" Then I should be 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 "Apocalypse Now" And I select "R" from "Rating" And I press "Save Changes" Then I should be on the RottenPotatoes home page When I follow ”Movie Title" Then I should see "Apocalypse Now" before "Zorro" 5 Only step specifying behavior; Rest are implementation. But BDD specifies behavior, not implementation!

6 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 6

7 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 7 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?

8 Declarative Scenario Needs New Step Definitions Given /I have added "(.*)" with rating "(.*)"/ do |title, rating| steps %Q{Given I am on the Create New Movie page When I fill in "Title" with "#{title}” And I select "#{rating}" from "Rating" And I press "Save Changes“} end Then /I should see "(.*)" before "(.*)" on (.*)/ do |string1, string2, path| step “I am on #{path}" regexp = /#{string1}.*#{string2}/m # /m means match across newlines page.body.should =~ regexp end 8 As app evolves, reuse steps from first few imperative scenarios to create more concise and descriptive declarative scenarios

9 9 END

10 Declarative scenarios aim to capture implementation as well as behavior All are false Explicit requirements are usually defined with imperative scenarios and implicit requirements are usually defined with declarative scenarios 10 Which is TRUE about implicit vs. explicit and declarative vs. imperative scenarios?

11 11 END

12 Fallacies & Pitfalls, BDD Pros & Cons, End of Chapter 7 (Engineering Software as a Service §7.11) 12 © 2013 Armando Fox & David Patterson, all rights reserved

13 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

14 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

15 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

16 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

17 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

18 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

19 19 END

20 A BDD downside is that it may lead to a poor software architecture, since focus is on behavior None are false; all three above are true The purpose of the Lo-Fi UI approach is to debug the UI before you program it 20 Which statement is FALSE about Lo-FI UI and BDD?

21 21 END

22 How Popular is Agile? IT SW companies using Agile: Amazon, eBay, Facebook, Microsoft, Salesforce, … 2011 Survey of UCB ESaaS Alumni in industry –68% Agile vs. 32% P&D (5% Spiral, 5% Waterfall) 2012 survey of 66 distributed projects* –55% Agile vs. 45% P&D Forrester: 60% teams use Agile as primary SW development in 2012 vs. 45% in 2009** Gartner: 80% teams primarily Agile by end of 2012*** 22 *H.-C. Estler, M. Nordio, C. A. Furia, B. Meyer, and J. Schneider. Agile vs. structured distributed software development: A case study. Proc. 7th Int’l Conf. on Global Software Engineering (ICGSE’12), pp 11–20, **http://articles.economictimes.indiatimes.com/ /news/ _1_thoughtworks-software-development-iterative. ***http://www.pmi.org/en/Professional-Development/Career-Central/Must_Have_Skill_Agile.aspx.

23 23 Testing Tools in Book (Figure 7.15, Software as a Service by Armando Fox and David Patterson, 1 st edition, 2013.)

24 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 24 Images used for satire purposes only

25 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 25

26 26 END

27 RSpec on Rails (Engineering Software as a Service §8.2) © 2012 Armando Fox & David Patterson Licensed under Creative Commons Attribution- NonCommercial-ShareAlike 3.0 Unported LicenseCreative Commons Attribution- NonCommercial-ShareAlike 3.0 Unported License

28 Rspec: Domain-Specific Language for Testing RSpec tests (specs) inhabit spec directory rails generate rspec:install creates structure Unit tests (model, helpers) Functional tests (controllers) Integration tests (views)? app/models/*.rbspec/models/*_spec.rb app/controllers/ *_controller.rb spec/controllers/ *_controller_spec.rb app/views/*/*.html.haml (use Cucumber!)

29 Example: Calling TMDb New RottenPotatoes feature: add movie using info from TMDb (vs. typing in) How should user story steps behave? When I fill in "Search Terms" with "Inception" And I press "Search TMDb" Then I should be on the RottenPotatoes homepage... Recall Rails Cookery #2: adding new feature == new route+new controller method+new view

30 The Code You Wish You Had What should the controller method do that receives the search form? 1. It should call a method that will search TMDb for specified movie 2. If match found: it should select (new) “Search Results” view to display match 3. If no match found: it should redirect to RP home page with message

31 31 END

32 A controller method A helper method A class method of the Movie model ☐ ☐ ☐ ☐ 32 The method that contacts TMDb to search for a movie should be:

33 33 END

34 The TDD Cycle: Red–Green–Refactor (Engineering Software as a Service §8.2) © 2013 Armando Fox & David Patterson, all rights reserved

35 Test-First Development Think about one thing the code should do Capture that thought in a test, which fails Write the simplest possible code that lets the test pass Refactor: DRY out commonality w/other tests Continue with next thing code should do Red – Green – Refactor Aim for “always have working code”

36 How to test something “in isolation” if it has dependencies that would affect test?

37 The Code You Wish You Had What should the controller method do that receives the search form? 1. It should call a method that will search TMDb for specified movie 2. If match found: it should select (new) “Search Results” view to display match 3. If no match found: it should redirect to RP home page with message

38 TDD for the Controller Action: Setup Add a route to config/routes.rb # Route that posts 'Search TMDb' form post '/movies/search_tmdb' –Convention over configuration will map this to MoviesController#search_tmdb Create an empty view: touch app/views/movies/search_tmdb.html.haml Replace fake “hardwired” sad path method in movies_controller.rb with empty method: def search_tmdb end

39 What Model Method? Calling TMDb is responsibility of the model... but no model method exists to do this yet! No problem...we’ll use a seam to test the code we wish we had (“CWWWH”), Movie.find_in_tmdb Game plan: –Simulate POSTing search form to controller action. –Check that controller action tries to call Movie.find_in_tmdb with data from submitted form –The test will fail (red), because the (empty) controller method doesn’t call find_in_tmdb –Fix controller action to make green

40 40 END

41 It can be issued either before or after the code that should make the call It exploits Ruby’s open classes and metaprogramming to create a seam It provides a stand-in for a real method that doesn’t exist yet ☐ ☐ ☐ ☐ 41 Which is FALSE about should_receive ?

42 42 END

43 Seams (Engineering Software as a Service §8.3) © 2013 Armando Fox & David Patterson, all rights reserved

44 Seams A place where you can change app’s behavior without changing source code. (Michael Feathers, Working Effectively With Legacy Code) Useful for testing: isolate behavior of some code from that of other code it depends on. should_receive uses Ruby’s open classes to create a seam for isolating controller action from behavior of (possibly buggy or missing) Movie.find_in_tmdb Rspec resets all mocks & stubs after each example (keep tests Independent)

45 How to Make This Spec Green? Expectation says controller action should call Movie.find_in_tmdb So, let’s call it! The spec has driven the creation of the controller method to pass the test But shouldn’t find_in_tmdb return something?

46 Optional! obj.should_receive(a).with(b) Test Techniques We Know

47 47 END

48 Keep the should_receive seam in the spec, but if necessary, change the spec to match the API of the real find_in_tmdb Remove this spec (test case) altogether since it isn’t really testing anything anymore Replace the call to should_receive in our test with a call to the real find_in_tmdb ☐ ☐ ☐ ☐ 48 Eventually we will have to write a real find_in_tmdb. When that happens, we should:

49 49 END

50 Expectations (Engineering Software as a Service §8.4) © 2013 Armando Fox & David Patterson, all rights reserved

51 Where We Are & Where We’re Going: “Outside In” Development Focus: write expectations that drive development of controller method –Discovered: must collaborate w/model method –Use outside-in recursively: stub model method in this test, write it later Key idea: break dependency between method under test & its collaborators Key concept: seam—where you can affect app behavior without editing code

52 The Code You Wish You Had What should the controller method do that receives the search form? 1. It should call a method that will search TMDb for specified movie 2. If match found: it should select (new) “Search Results” view to display match 3. If no match found: it should redirect to RP home page with message

53 “It Should Select Search Results View to Display Match” Really 2 specs: 1. It should decide to render Search Results –more important when different views could be rendered depending on outcome 2. It should make list of matches available to that view New expectation construct: obj.should match-condition –Many built-in matchers, or define your own

54 Should & Should-Not Matcher applies test to receiver of should count.should == 5` Syntactic sugar for count.should.==(5) 5.should(be.<(7)) be creates a lambda that tests the predicate expression 5.should be < 7 Syntactic sugar allowed 5.should be_odd Use method_missing to call odd? on 5 result.should include(elt) calls #include?, which usually gets handled by Enumerable republican.should cooperate_with(democrat) calls programmer’s custom matcher #cooperate_with (and probably fails) result.should render_template('search_tmdb')

55 Checking for Rendering After post :search_tmdb, response() method returns controller’s response object render_template matcher can check what view the controller tried to render Note that this view has to exist! –post :search_tmdb will try to do the whole MVC flow, including rendering the view –hence, controller specs can be viewed as functional testing

56 Test Techniques We Know obj.should_receive(a).with(b) obj.should match-condition Rails-specific extensions to RSpec: response() render_template()

57 57 END

58 result.should_not match /^D'oh!$/ All of the above are valid uses result.should_not be_empty ☐ ☐ ☐ ☐ 58 Which of these, if any, is not a valid use of should or should_not ?

59 59 END


Download ppt "Explicit vs. Implicit and Imperative vs. Declarative Scenarios (Engineering Software as a Service §7.9) 1 © 2013 Armando Fox & David Patterson, all rights."

Similar presentations


Ads by Google