<div dir="ltr">Hi LRUG,<div><br></div><div>I've been bitten by bad unit tests in the past (mostly ones I've written myself), and lean towards integration tests (a la <a href="https://x.com/rauchg/status/807626710350839808">https://x.com/rauchg/status/807626710350839808</a>) when given the choice. But I want to believe good unit tests are achievable. A problem I often encounter is something like this:</div><div><br></div><div>Service A calls service B. The unit tests for service A mock service B using statements like "expect(B).to receive(:call).with(x).and_return(y)". But in reality (due to refactors over time or misunderstandings between teammates), if you passed x to service B you'd get a return value of z, or it would raise an ArgumentError. So the unit tests for A are  only passing because they're describing an impossible situation.</div><div><br></div><div>Are there any good patterns for constraining the arguments and return values stated in mocks somehow? I'd love it if something would check that the inputs and outputs I specify when mocking service B have been "proven" to be accurate in my unit tests for B. That way my unit tests could give me some of the benefits of (slower, unwieldier) integration tests "for free". Or am I being hopelessly naive and misguided here?</div><div><br></div><div>Patrick</div><div><i>Mediocre developer. Failed composer. Fledgeling novelist (<a href="https://bedfordsquarepublishers.co.uk/book/hattie-brings-the-house-down/">https://bedfordsquarepublishers.co.uk/book/hattie-brings-the-house-down/</a>).</i></div><div><br></div></div>