Skip to content

Instantly share code, notes, and snippets.

@bethesque
Last active August 29, 2015 14:02
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save bethesque/69ae590e8312523e5337 to your computer and use it in GitHub Desktop.
Save bethesque/69ae590e8312523e5337 to your computer and use it in GitHub Desktop.
Thoughts on verifying that mocked models are actually valid

It's about ensuring the model used to stub client responses can actually be produced by the response you expect. Imagine your client returns a model like so:

class MyModel
   attr_reader :timestamp
   
   def initialize attrs
      @timestamp = attr[:timestamp]
   end
end

In your unit test for the client, you expect that it returns an instance of the model with the timestamp that is a Time

expect(my_client.get_my_model).to eq(MyModel.new(timestamp: Time.new(2014, 06, 04, 01, 21, 54)))

But then you stub the client in another test to return a model, but here you expect the timestamp to be a DateTime (hypothetically, not that anyone I know has every done anything like this...)

allow(my_client).to receive(:get_my_model).and_return(MyModel.new(timestamp: DateTime.parse('2014-06-04T01:21:54+00:00'))

There is no test that will fail to alert you of the error. If you use a shared fixture or consistent way of creating the object so that the thing you stub with has been validated by the pact test as something that will actually be created, you won't have this problem.

# Maybe something like:

class MyModelFactory
   def self.create_my_model attrs
      #Do something to ensure that the timestamp is the right class
   end
end

Typed languages of course don't have this problem. One of the downsides of Ruby.

It's actually a repeat of the pattern that pact is based on - when you mock, you need some way to verify that your mocks are correct.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment