Testing Philosphies
Upcoming SlideShare
Loading in...5

Testing Philosphies



Rob Kaufman's slides from his SDRuby talk: Testing Philosophies

Rob Kaufman's slides from his SDRuby talk: Testing Philosophies



Total Views
Views on SlideShare
Embed Views



3 Embeds 23

http://notch8.com 18
http://www.notch8.com 3
http://www.slideshare.net 2



Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Testing Philosphies Testing Philosphies Presentation Transcript

    • Testing Philosophies by Rob Kaufman Notch8 notch8.com [email_address]
    • What are Testing Philosophies
    • A Glossary
      • Unit Test – Testing the inputs and outputs of a method
      • Functional Test – Does a whole set of methods accomplish what they set out too
      • Integration Test – Do the software components work together as desired
      • Acceptance Test – Does the user see/get what they expect
    • The When
    • The What
    • Don't Test
      • Testing is hard...and most developers aren’t very good at it!
      • You can’t test code that isn’t there
      • Tests are just as likely to contain bugs
      • Should focus on code reviews, writing good code and user level testing (acceptance tests)
    • Don't Test
      • Hampton Catlin
        • Apps include Wikipedia Mobile
        • Considered a great developer
        • Hates automated code testing
    • Test Everything - TATFT
      • Every line of code you have test coverage
      • Is really a whole school of philosophies
      • Often is thought to include some sort of CI tool, but doesn't have to
    • All About the Units
      • Tests should be modular and small
      • Should test the interface (input and output) of a method and any side effects
      • Test should focus on a given part of an individual method
      • Tests should only rely on themselves and nothing else (1)
      • In classic rspec model, controller and view tests are all focused at unit levels
    • Unit Independence
      • Keep each test completely independent of other tests
      • Use mocks and stubs
    • All about the Integration
      • Only test the system as a whole
      • Similar to acceptance testing, but automated and programmatic
      • Cucumber, Fitness, etc are common tools for this
    • Russian Dolls Testing
      • Test models at the unit level
      • Do functional testing at the controller level
      • Do integration testing at the view level
      • Is the default in Rails with Test::Unit
    • Unit Test + Integrate
      • Test method inputs and outputs where its helpful, then test how the whole things works together
      • Merb Request specs
      • Request specs will become the default rSpec test for Rails 3
    • Throw Down?
    • Discussion!