The document discusses best practices for testing with mocks in Ruby on Rails applications. It recommends that tests run fast by avoiding loading Rails and using factories, and that mocks should assert messages rather than state. Tests become more maintainable by mocking roles instead of concrete objects, and by isolating code into single responsibility classes rather than putting logic in fat models. When code is well-encapsulated with messages, mocks can make tests clearer; but mocks may indicate problems when they are difficult to set up or when tests become brittle.

1. Testing Gone Right
from RubyConf 2011 and others
@jwo - Jesse Wolgamott

2. What We’ll Talk Abouts

3. What We’ll Talk Abouts
• Mock is not a 4 letter word
• Fast tests. Really Fast.
• Rails Models

4. Mock is not a 4 letter
word

5. Mocks

6. Mocks
• Mocks are not stubs

7. Mocks
• Mocks are not stubs
• Mocks assert Messages

8. Mocks
• Mocks are not stubs
• Mocks assert Messages
• Assert on state => Stubbing

9. Mocks
• Mocks are not stubs
• Mocks assert Messages
• Assert on state => Stubbing
• Assert on messages => Mocking

10. Ruby + OOP + Mock

11. Ruby + OOP + Mock
• is goood

12. Ruby + OOP + Mock
• is goood
• Objects should tell objects to do things

13. Ruby + OOP + Mock
• is goood
• Objects should tell objects to do things
• (Tell don’t ask)

14. Ruby + OOP + Mock
• is goood
• Objects should tell objects to do things
• (Tell don’t ask)
• You tell to do things using messages

15. Mock Roles
• Instead of mocking objects, try to mock
roles
• Wanting to mock concrete objects is a
design smell

16. Example

17. Example
• Restaurant system reserves tables
• Instead of your interface talking to a
ReservationService:
• Talk to ReservationInterfaceHandler

18. 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

19. 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

20. Watch Out!

21. On APIs
• Only Mock Types you own
• Don’t mock boundary objects
• If you do, you’ll duplicate code -> CODE
SMELL

22. Other Mock Smells

23. Other Mock Smells
• Having to setup more than 3 lines -- that’s a
code smell

24. Other Mock Smells
• Having to setup more than 3 lines -- that’s a
code smell
• Mocking concrete objects -- that’s a code
smell

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

26. However

27. However
• If you have a “standard” Rails app,
programmed procedurally:

28. However
• If you have a “standard” Rails app,
programmed procedurally:
• Mocks are not for you

29. 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:

30. 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!

31. Mocks Don’t Suck

32. Mocks Don’t Suck
• If your code is hard to test, you need better
code

33. 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

34. 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

35. Fast Rails Tests

36. Out of the Box

37. Out of the Box
• Most Rails apps start as CRUD apps

38. Out of the Box
• Most Rails apps start as CRUD apps
• Tests start fast-ish

39. Out of the Box
• Most Rails apps start as CRUD apps
• Tests start fast-ish
• Like a frog, we don’t notice the increase

40. “fast” tests
• Tests should run in under a second
• The entire rspec test suite

41. How?
• Don’t load rails

42. Example
Spec Run
Real Time
Time
With Rails .07 s 8.1 s
Without
0.0007 s .8 s
Rails

43. Avoid Factories

44. Avoid Factories
• Instead, extract your code to classes with
one single responsibility

45. Avoid Factories
• Instead, extract your code to classes with
one single responsibility
• Rather than knowing everything about your
object

46. Avoid Factories
• Instead, extract your code to classes with
one single responsibility
• Rather than knowing everything about your
object
• Or, load methods via modules

47. Rails Models

48. Rails Models
• Are Fat.

49. Rails Models
• Are Fat.
• Wait, isn’t that good?

50. Rails Models
• Are Fat.
• Wait, isn’t that good?
• It’s better than controller logic

51. Rails Models
• Are Fat.
• Wait, isn’t that good?
• It’s better than controller logic
• But no.

52. What then?

53. What then?
• Your models can have validations

54. What then?
• Your models can have validations
• Call out to policy or decision classes for
business logic

55. What then?
• Your models can have validations
• Call out to policy or decision classes for
business logic
• Use Ruby Classes

56. What then?
• Your models can have validations
• Call out to policy or decision classes for
business logic
• Use Ruby Classes
• Use Presenters

57. 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

58. 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.
@garybernhardt
destroyalldoftware.com