Sessions at RubyConf 2011 about Mocking

Thursday 29th September 2011

• Why You Don't Get Mock Objects

  by Gregory Moeck

  Although the Ruby community has embraced TDD like no other community ever has, we have always looked at mock objects with disdain, and perhaps even a little hatred. I've heard conference speakers call them "Wastes of time", "Scams", and even "Testing Heresies". Why would anyone have ever developed these pieces of junk?

  In reality though many in the agile community have embraced mock objects within their testing cycles because they have found using these fake objects improves the design of their systems. But why not Rubyists? Most Rubyists don't get mock objects because they don't understand their history or their creators intent. They try to fit them into their current workflow without understanding them, and find them unhelpful and stupid. After all, almost all of the good literature on the subject is written in Java, and we know how frustrating it is to read Java when your used to Ruby.

  As such, this talk will attempt to demonstrate in Ruby the usefulness of mock objects, and how to use them to improve the design of your system.

  Specifically the following will be covered:

  • Why do we need mock objects (Following the 'Tell, Don't Ask Principle')
  • Why you should only mock objects you own
  • Why you shouldn't use mocks to test boundary objects like external API calls
  • Why you should mock roles, not Objects
  • Why you should only mock your immediate neighbors
  • Why listening to your unit tests will tell you about design problems in your code
  • Mocking
  • Ruby
  • Test Driven Development

  At 11:15am to 12:00pm, Thursday 29th September

  Coverage slide deck video

Friday 30th September 2011

• Your tests are lying to you

  by Chris Parsons

  Mocks have an a bad rap lately. We've all seen brittle and unreadable test code riddled with 'should_receive' and 'mock_model', leading to classes people don't dare to touch. RSpec has now taken "mock_model" out of their default scaffolding for Rails controllers, and is preferring real objects. Does this mean that the concept of interaction testing is flawed?

  Well designed code is easy to test, and mocks enhance your sense of smell. State-based testing will lie to you and hide your bad code for longer, but your interaction tests explode if you don't keep your code clean and your object collaborators few. That's as it should be.

  Come to this talk if you want to hear a robust defence of mocks as a testing tool, see some examples of ruby code exhibiting the dangers of a reliance on state-based testing, and hear how you can use mocks to heighten your sense of smell, decrease coupling and increase cohesion.

  • Mocking
  • Ruby
  • Testing

  At 5:15pm to 6:00pm, Friday 30th September

  Coverage slide deck video