←back to thread

67 points ingve | 1 comments | | HN request time: 0.207s | source
Show context
lelandbatey ◴[] No.45949894[source]
I feel like the #1 reason mocks break looks nothing like this and instead looks like: you change the internal behaviors of a function/method and now the mocks interact differently with the underlying code, forcing you to change the mocks. Which highlights how awful mocking as a concept is; it is of truly limited usefulness for anything but the most brittle of tests.

Don't test the wrong things; if you care about some precondition, that should be an input. If you need to measure a side effect, that should be an output. Don't tweak global state to do your testing.

replies(3): >>45950085 #>>45951034 #>>45955029 #
wry_discontent ◴[] No.45955029[source]
I see a lot of times people (read: me) are lazy and make a mock that does not have anywhere near the behavior of the original. It's more like a very partial stub. I will mock an api with 20 possible calls with the 2 that I use. Unsurprisingly, this mock is closely tied to the current implementation.
replies(1): >>45968018 #
1. bccdee ◴[] No.45968018[source]
I think making narrow use-case-specific test doubles is often better than a big shared one. You can even wrap the API with an interface that only exposes the methods you need.