33 ms·
The biggest issue that ever comes up for me when using mocks is getting the assumptions wrong. For instance perhaps I mock my interactions with an external web
by ericmoritz 16y ago
The biggest issue that ever comes up for me when using mocks is getting the assumptions wrong. For instance perhaps I mock my interactions with an external web service and they change the JSON structure on me. My tests continue to pass but in production, bad things happen.
- jdminhbg 16y agoI've been using ephemeral_response[1] in Ruby, there may be a similar library in whatever language you're working with. The idea is that it makes one real call to the service and caches it for a specified amount of time as a fixture. That way you don't constantly make calls against e.g. the Twitter search api, but when they change how it works in 6 months, your test will fail. [1]: https://github.com/sandro/ephemeral_response https://github.com/sandro/ephemeral_response
- jjrumi 16y agoI don't know if ephemeral_response solves this, but the first thing that comes into my mind is caching an error (webservice doesn't respond in time or whatever). This happened to me some times. Caching the error is a big problem when you have a system that determines if your code is stable or not and blocks deployments in production to prevent errors.
- masklinn 16y agoIt does not bother me that my unit tests can't tell me the power just went down or my graphic card is going up in flames. That's not their job at all. So that's not an issue at all, that's not relevant. The best thing tests can do (and what they should do) is ensure your code behaves "correctly" in the face of invalid or corrupted data, which an unexpected JSON structure would certainly be.