CS 98/198: Web 2.0 Applications Using Ruby on Rails

CS 98/198: Web 2.0 Applications Using Ruby on Rails

Mocks and Stubs (Engineering Software as a Service 8.4) 2013 Armando Fox & David Patterson, all rights reserved It Should Make Search Results Available to Template Another rspec-rails addition: assigns() pass symbol that names controller instance variable returns value that controller assigned to variable

But our current code doesnt set any http://pastebin.com/DxzFURiu instance variables: TCWWWH: list of matches in @movies http://pastebin.com/4W08wL0X Two New Seam Concepts stub similar to should_receive, but not expectation and_return optionally controls return value mock: stunt double object, often used for

behavior verification (did method get called) stub individual methods on it: m=double('movie1',:title=>'Rambo') each seam enables just enough functionality for some specific behavior under test RSpec Cookery #1 Each spec should test just one behavior Use seams as needed to isolate that behavior Determine what type of expectation will

check the behavior Write the test and make sure it fails for the right reason Add code until test is green Look for opportunities to refactor/beautify Test Techniques We Know obj.should_receive(a).with(b).and_return(c) obj.stub(a).and_return(b) Optional! d = double('impostor') obj.should match-condition

Rails-specific extensions to RSpec: assigns(:instance_var) response() render_template() END 6 should_receive combines _____ and _____,

whereas stub is only _____. A mock and an expectation; a double A mock and an expectation; an expectation A seam and an expectation; an expectation A seam and an expectation;

a seam 7 END 8 Fixtures and Factories (Engineering Software as a Service 8.5) 2013 Armando Fox & David Patterson, all rights reserved

When You Need the Real Thing http://pastebin.com/N3s1A193 Where to get a real object: Fixture: statically preload some known data into database tables Factory: create only what you need pertest Fixtures Database wiped & reloaded before each spec add fixtures :movies at beginning of describe spec/fixtures/movies.yml are Movies

and will be added to movies table Pros/uses truly static data, e.g. configuration info that never changes easy to see all test data in one place Cons/reasons not to use may introduce dependency on fixture data Factories Set up helpers to quickly create objects

with default attributes, as needed per-test Example: FactoryGirl gem http://pastebin.com/bzvKG0VB or just add your own code in spec/support/ Pros/uses: Keep tests Independent: unaffected by presence of objects they dont care about Cons/reasons not to use: Complex relationships may be hard to set up (but may indicate too-tight coupling in code!)

Pitfall: mock trainwreck Goal: test searching for movie by its director or by awards it received m.award.type.should == 'Oscar' m.director.name.split(/ +/).last. should == 'Aronovsky' Mock setup: a = double('Award', :type => 'Oscar') d = double('Director', :name => 'Darren Aronovsky'

m = double('Movie', :award => a, :director => d) END 14 Which of the following kinds of data, if any, should not be set up as fixtures? Movies and their ratings The TMDb API key The applications time zone settings

Fixtures would be fine for all of these 15 END 16 TDD for the Model & Stubbing the Internet (Engineering Software as a Service 8.6) 2013 Armando Fox & David Patterson, all rights reserved

Explicit vs. Implicit Requirements find_in_tmdb should call TmdbRuby gem with title keywords If we had no gem: It should directly submit a RESTful URI to remote TMDb site What if TmdbRuby gem signals error? API key is invalid API key is not provided

Use context & describe to divide up tests http://pastebin.com/ELQfC8Je Review Implicit requirements derived from explicit by reading docs/specs as byproduct of designing classes We used 2 different stubbing approaches case 1: we know TMDb gem will immediately throw error; test that we catch & convert it case 2: need to prevent gem from contacting

TMDb at all context & describe group similar tests in book: using before(:each) to setup common preconditions that apply to whole group of tests Where to Stub in Service Oriented Architecture? movie.rb ruby-tmdb Net::HTTP/ OpenURI

OS - TCP/IP Internet TMDb TMDb-dev Movie.stub(:find_in_tmdb). and_return(...) TmdbMovie.stub(:find).with(...). Ruleand_return(...) of thumb:

Net::HTTP.stub(:get). for unit testing, stub nearby, for with(...). maximum isolation of class and_return(...) under test (Fast, Independent) for integration testing, stub far away, to test as many interfaces as possible

Parse contrived request Return canned value(s) (using FakeWeb gem, for example) Test Techniques We Know obj.should_receive(a).with(b).and_return(c) .with(hash_including 'k'=>'v') obj.stub(a).and_raise(SomeClass::SomeError) d = double('impostor') { action }.should raise_error(Some::Error) describe, context

Rails-specific extensions to RSpec: assigns(:instance_var) response() render_template() END 22 Which statement(s) are TRUE about Implicit requirements? They are often, but not always,

derived from explicit requirements They apply only to unit & functional tests, not integration tests Testing them is lower priority than testing explicit requirements, since they dont come from the customer All of the above are true 23 END 24

Coverage, Unit vs. Integration Tests (Engineering Software as a Service 8.7) 2013 Armando Fox & David Patterson, all rights reserved How Much Testing is Enough? Bad: Until time to ship A bit better: (Lines of test) / (Lines of code) 1.21.5 not unreasonable Often much higher for production systems

Better question: How thorough is my testing? Formal methods Coverage measurement We focus on the latter, though the former is gaining traction Measuring Coverage - Basics class MyClass def foo(x,y,z) if x

if (y && z) then bar(0) end else bar(1) end end def bar(x) ; @w = x ; end end S0: every method called S1: every method from every call site C0: every statement

Ruby SimpleCov gem C1: every branch in both directions C1+decision coverage: every subexpression in conditional C2: every path (difficult, and disagreement on how valuable) What Kinds of Tests?

Unit (one method/class) e.g. model specs Functional or module (few methods/classes) e.g. ctrlr

specs Integration/system e.g. Cuke scenarios Runs fast High coverage Fine resolution Many mocks; Doesnt test interfaces

Few mocksf; tests interfaces Runs slow Low coverage Coarse resolution Going to Extremes I kicked the tires, it works Dont ship until 100% covered & green Use coverage to identify untested or undertested parts of code Focus on unit tests, theyre more thorough

Focus on integration tests, theyre more realistic Each finds bugs the other misses END 30 Which of these is POOR advice for TDD? Mock & stub early & often in unit tests

Aim for high unit test coverage Sometimes its OK to use stubs & mocks in integration tests Unit tests give you higher confidence of system correctness than integration

tests 31 END 32 Other Testing Concepts; Testing vs. Debugging (Engineering Software as a Service 8.8, 8.11)

2013 Armando Fox & David Patterson, all rights reserved Other Testing Terms You May Hear Mutation testing: introduce deliberate error in code, do tests fail? Fuzz testing: 10,000 monkeys throw random input at your code Find ~20% MS bugs, crash ~25% UNIX utilities Tests app the way it wasnt meant to be used DU-coverage: is every pair executed?

Black-box vs. white-box/glass-box TDD vs. Conventional Debugging Conventional TDD Write 10s of lines, run, hit bug: break out debugger Write a few lines, with test first; know immediately if broken

Insert printfs to print variables while running repeatedly Test short pieces of code using expectations Stop in debugger, tweak/set variables to Use mocks and stubs to control code control code path path Darn, I thought for sure I fixed it, now have to do this all again

Re-run test automatically Lesson 1: TDD uses same skills & techniques as conventional debugging - but more productive (FIRST) Lesson 2: writing tests before code takes more time up-front, but often less time overall TDD Summary Red Green Refactor, and always have working code Test one behavior at a time, using seams

Use it placeholders or pending to note tests you know youll need Read & understand coverage reports Defense in depth: dont rely too heavily on any one kind of test They only hit what they are aiming at END 37 Which non-obvious statement about testing is FALSE?

Even 100% test coverage is not a guarantee of being bug-free If you can stimulate a bug-causing condition in a debugger, you can capture it in a test Testing eliminates the need to use a debugger When you change your code, you need to change your tests as well

38 END 39 Plan-And-Document Perspective on Software Testing (Engineering Software as a Service 8.9) 2013 Armando Fox & David Patterson, all rights reserved 40

P&D Testing? BDD/TDD writes tests before code When do P&D developers write tests? BDD/TDD starts from user stories Where do P&D developers start? BDD/TDD developers write tests & code Does P&D use same or different people for testing and coding?

What does the Testing Plan and Testing Documentation look like? 41 P&D Project Manager P&D depends on Project Managers Document project management plan Creates Software Requirements Specification (SRS) Can be 100s of pages IEEE standard to follow

Must document Test Plan IEEE standard to follow 42 P&D Approach to Testing Manager divides SRS into programming units Developers code units Developers perform unit testing Separate Quality Assurance (QA) team does higher level tests: Module, Integration, System,

Acceptance 43 3 QA Integration Options 1. Top-down integration Start at top of dependency graph High-level functions (UI) work soon Many stubs to get app to work 2. Bottom-up integration Start at bottom of dependency graph

No stubs, integrate everything in a module Cant see app working until all code written & integrated 44 3 QA Integration Options 3. Sandwich integration Best of both worlds? Reduce stubs by integrating some units bottom up Try to get UI operational by

integrating some units top down 45 QA Team Testing Next QA Team does System Test Full app should work Test non-functional requirements (performance) + functional requirements (features in SRS) When is P&D System Testing Done?

Organization policy E.g., test coverage level (e.g. all statements) E.g., all inputs tested with good and bad data Final step: Customer or User Acceptance tests (UAT) - validation vs. verification 46 Limits of Testing Program testing can be used to show the presence of bugs, but never to show their absence!

Edsger W. Dijkstra (received the 1972 Turing Award for fundamental contributions to developing programming languages) (Photo by Hamilton Richards. Used by permission under CC-BY-SA-3.0.) 47 Formal Methods Start with formal specification & prove

program behavior follows spec. 1. Human does proof 2. Computer via automatic theorem proving Uses inference + logical axioms to produce proofs from scratch 3. Computer via model checking Verifies selected properties by exhaustive search of all possible states that a system could enter during execution

48 Formal Methods Computationally expensive, so use when Small, fixed function Expensive to repair, very hard to test E.g. Network protocols, safety critical SW Biggest: OS kernel 10K LOC @ $500/LOC NASA SW $80/LOC

This course: rapidly changing SW (SaaS), easy to repair, easy to test => no formal methods 49 SW Testing: P&D vs. Agile (Fig. 8.23) 50 END

51 Which statement regarding testing is FALSE? 1. Formal methods are expensive but worthwhile to verify important applications 2. P&D

developers code before they write tests while its vice versa for Agile developers 3. Agile developers perform module, integration, system, and acceptance tests; P&D developers dont 4. Sandwich integration in P&D aims to reduce effort making stubs while trying to get general functionality early 52

END 53

Recently Viewed Presentations

  • Foundations of Multinational Financial Management Alan Shapiro John

    Foundations of Multinational Financial Management Alan Shapiro John

    THE EUROMARKETS -the most important international financial markets today. A. The Eurocurrency Market 1. Composed of eurobanks who accept/ maintain deposits of foreign currency 2. Dominant currency: US$ THE EUROMARKETS B. Growth of Eurodollar Market caused by restrictive US government...
  • Entrepreneurship: Make Your Mark! Presenter Name, Ph.D. Presenter

    Entrepreneurship: Make Your Mark! Presenter Name, Ph.D. Presenter

    Muhammad Yunus (Bangladesh) - Founder of microcredit. Winner of 2006 Nobel Peace prize Who is an Entrepreneur in the area you are interested in? The arts? Politics? Social justice? Business? Architecture? Athletics? Sciences?
  • 921: Childhood Mental Health Issues: An Introduction for

    921: Childhood Mental Health Issues: An Introduction for

    Competencies. The foster parent knows how to assist in treatment of children with mental health or behavioral disorders, including discussion of feelings and concerns, problem solving, empathic listening, behavior management, de-escalation, sanctioned physical restraint, and assault prevention.
  • Health Profile of Sheffield - ADPH

    Health Profile of Sheffield - ADPH

    Addressing health inequalities in Sheffield Jeremy Wight, Director of Public Health Cath Roff, Director of Adults' Services Health in Sheffield 500,000 People Diverse geography/ population City never healthier than now Infant mortality, at around 5 deaths per 1000 live births,...
  • Political Institutions: The Congress

    Political Institutions: The Congress

    Striking down a Texas law that banned flag burning in Texas v. Johnson, 1989, and then striking down a congressional law that banned flag burning (US v. Eichmann) Striking down the Gun Free School Zones Act in US v. Lopez,...
  • Optimal Deposit Insurance Eduardo Dvila (NYU, Stern) Itay

    Optimal Deposit Insurance Eduardo Dvila (NYU, Stern) Itay

    In Diamond and Dybvig (1983): Unlimited insurance: insurance works to prevent failures altogether and so has no cost In the real world: Insurance always limited; e.g., in US current maximum for insurance is $250,000, which was increased from $100,000 in...
  • Develop a foundational knowledge of PRICING to understand its ...

    Develop a foundational knowledge of PRICING to understand its ...

    Develop a foundational knowledge of PRICING to understand its role in marketing. 4.07. IDENTIFY FACTORS AFFECTING PRICING and PRICING ISSUESOF SEM PRODUCTS. FACTORS AFFECTING PRICING OF SEM PRODUCTS. LEAD TIME. MARKET DEMAND. How much of a product customers will buy...
  • Ajax, JavaScript and PHP

    Ajax, JavaScript and PHP

    HTML Syntax HTML (or AKA HTML5) defines a syntax, referred to as "the HTML syntax", that is mostly compatible with HTML4 and XHTML1 documents published on the Web, but is not compatible with the more esoteric SGML features of HTML4....