4 ms·

Why mocking is a bad idea

1 points by fagnerbrack 4y ago

onion2k 4y ago
Isn't the massive benefit of mocking that you can test scenarios that are really hard to test with real libraries? Taking the Stripe Server call as an example, if you use the real thing then getting it to return a specific error, or a making it fail in a deterministic way, or pretending Stripe has been hacked and is returning a GIF of an owl for every response, is pretty much impossible. If you use a mock that has the same API as the real thing then you get to control what's returned in all manner of different scenarios, which means you can test all those cases. Sure, Stripe might have a real bug, and that would impact your code, but at least you can know that your code will fail gracefully because you mocked that exact scenario. Testing, and testing with mocks especially, is not about proving your code works when things are right. It's about proving your code fails properly when things are wrong. If you're not hunting down cases where things fail then you're not testing well enough.
- daviddever23box 4y ago
  Agreed - integration testing will not help you when your code is actually functional against a remote API server that is broken (or poorly documented). The extra work required to properly separate concerns near to a foreign API surface, in my experience, pays for itself: you expected (and wrote tests for) three outcomes, and provided an observability hook for those outcomes, but a fourth raises its ugly head in real life, forcing you to revisit the API docs and add it to your mock. You add references to the API doc relative to those outcomes, and your code can be easily followed and troubleshooted by the next person. What's not to like? I feel as if I've seen the same arguments raised over and over against mocks, all of which fall back to "I'm too lazy to maintain the state-space of unit tests", which is, quite frankly, not my problem–it's yours. Grow up and be responsible.

4 ms·

Why mocking is a bad idea

1 points by fagnerbrack 4y ago

onion2k 4y ago
Isn't the massive benefit of mocking that you can test scenarios that are really hard to test with real libraries? Taking the Stripe Server call as an example, if you use the real thing then getting it to return a specific error, or a making it fail in a deterministic way, or pretending Stripe has been hacked and is returning a GIF of an owl for every response, is pretty much impossible. If you use a mock that has the same API as the real thing then you get to control what's returned in all manner of different scenarios, which means you can test all those cases. Sure, Stripe might have a real bug, and that would impact your code, but at least you can know that your code will fail gracefully because you mocked that exact scenario. Testing, and testing with mocks especially, is not about proving your code works when things are right. It's about proving your code fails properly when things are wrong. If you're not hunting down cases where things fail then you're not testing well enough.
- daviddever23box 4y ago
  Agreed - integration testing will not help you when your code is actually functional against a remote API server that is broken (or poorly documented). The extra work required to properly separate concerns near to a foreign API surface, in my experience, pays for itself: you expected (and wrote tests for) three outcomes, and provided an observability hook for those outcomes, but a fourth raises its ugly head in real life, forcing you to revisit the API docs and add it to your mock. You add references to the API doc relative to those outcomes, and your code can be easily followed and troubleshooted by the next person. What's not to like? I feel as if I've seen the same arguments raised over and over against mocks, all of which fall back to "I'm too lazy to maintain the state-space of unit tests", which is, quite frankly, not my problem–it's yours. Grow up and be responsible.