<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 6, 2024 at 12:01 PM Patrick Gleeson <<a href="mailto:patrick.c.gleeson@gmail.com">patrick.c.gleeson@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><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></blockquote><div><br></div><div>Semi non answer (in that it doesn't help with mocks that don't behave the same as their thing[1]) but i find that a type system is  helpful here - ensuring that foo is only passed an instance of X and that it always returns a Y (& not nil in some case). I use sorbet i some apps and  i don't always love it, but it has its moments</div><div><br></div><div>Fred</div><div><br></div><div>[1] although one could imagine a `sorbet_double(Foo)` class that when you do `receive(:bar).with(baz).and_return(z)` checks whether those are valid arguments / return tipes</div></div></div>