Downsides to using FakeWeb compared to writing mocks for testing

Question

I never liked writing mocks and a while ago someone here recommended to use FakeWeb. I immediately fell completely in love with FakeWeb. However, I have to wonder if there is a downside to using FakeWeb. It seems like mocks are still much more common, so I wonder what I am missing that's wrong with using FakeWeb instead. Is there a certain kind of error you can't cover with Fakeweb or is it something about the TDD or BDD process?

Answer 1

You will probably get happy with VCR, which is a wrapper around HTTP mocking libraries. It caches the original HTTP requests, so that your tests are fast and work offline, but can also be changed to execute the original request again, to see if the test works against the remote API.

https://github.com/myronmarston/vcr

Answer 2

You should take a look at WebMock http://github.com/bblimke/webmock

The downside of mocking http requests is the lack of protection against remote API changes. If remote HTTP service changes, and your code won't be compatible anymore, your tests won't tell you about it. If you mock http client methods on your own, you have the same problems. It's good to have some integration test suite which verifies that your code can still talk to real http service.

The advantage of library like FakeWeb or WebMock is the fact that you can focus on implementing behaviour instead of worrying about implementation details of specific http client library. Even if you change library from for example Net::HTTP to RestClient, the behaviour should still be preserved so the tests should still be passing. If you mock http client on your own, you have to change tests when you change implementation, even if behaviour didn't change. Using FakeWeb or Webmock also helps with TDD or BDD (test first). You can specify the http behaviour with specs or tests, before worrying about implementation details of specific http client.