Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Testing Gone Right

Testing Gone Right

Mock is not a 4 letter word
Fast tests. Really Fast.
Rails Models

Jesse Wolgamott

December 07, 2011
Tweet

More Decks by Jesse Wolgamott

Other Decks in Programming

Transcript

  1. What We’ll Talk Abouts • Mock is not a 4

    letter word • Fast tests. Really Fast. • Rails Models
  2. Mocks • Mocks are not stubs • Mocks assert Messages

    • Assert on state => Stubbing • Assert on messages => Mocking
  3. Ruby + OOP + Mock • is goood • Objects

    should tell objects to do things • (Tell don’t ask) • You tell to do things using messages
  4. Mock Roles • Instead of mocking objects, try to mock

    roles • Wanting to mock concrete objects is a design smell
  5. Example • Restaurant system reserves tables • Instead of your

    interface talking to a ReservationService: • Talk to ReservationInterfaceHandler
  6. Message Example class ReservationInterface def initialize(handler) @handler = handler end

    def select_table(table) @table = table end def submit_request @handler.reserve(@table) end end
  7. And to Spec it describe ReservationInterface do let(:table){something_interesting_here} it "should

    tell the handler to reserve a table" do handler = double('reservation_handler') handler.should_receive(:reserve).with(table) machine = ReservationInterface.new(handler) machine.select_table(table) machine.submit_request end
  8. On APIs • Only Mock Types you own • Don’t

    mock boundary objects • If you do, you’ll duplicate code -> CODE SMELL
  9. Other Mock Smells • Having to setup more than 3

    lines -- that’s a code smell • Mocking concrete objects -- that’s a code smell • When tests go brittle and developers declare mocks suck -- that’s a code smell
  10. However • If you have a “standard” Rails app, programmed

    procedurally: • Mocks are not for you • If you encapulate your code. If you hide information (OOP). If you use messages: • Mocks are for you!
  11. Mocks Don’t Suck • If your code is hard to

    test, you need better code • If you have a test that is HARD to setup, your class (or test) is doing too much • If you see tests with uber-mocks, the answer is not to delete mocks. It’s to isolate your tests
  12. Out of the Box • Most Rails apps start as

    CRUD apps • Tests start fast-ish • Like a frog, we don’t notice the increase
  13. Avoid Factories • Instead, extract your code to classes with

    one single responsibility • Rather than knowing everything about your object • Or, load methods via modules
  14. Rails Models • Are Fat. • Wait, isn’t that good?

    • It’s better than controller logic • But no.
  15. What then? • Your models can have validations • Call

    out to policy or decision classes for business logic • Use Ruby Classes • Use Presenters
  16. Example • Example of building a burrito that is delicious,

    and can know it’s delicious • In Isolation: https://gist.github.com/1281093 • Using Modules: https://gist.github.com/ 1281064
  17. Credits Why you don’t get mock objects @gregmoeck Your tests

    are lying to you @chrismdp Fast Rails talk at gogoruco 2011 @coreyhaines Testing in Isolation. destroyalldoftware.com @garybernhardt