[LRUG] Joined-up unit tests

[Tom Close]

Sounds like you're describing pact
<https://github.com/pact-foundation/pact-ruby>. I haven't used it myself,
but maybe others here have?

Tom

On Thu, 6 Jun 2024 at 13:32, Rory Sinclair <rory at asmallworld.net> wrote:

> This is an interesting question. I wonder if it would be possible for B to
> "own" its mock implementation and somehow publish that as an artefact that
> A's tests depend on? So the maintainers of B can maintain a mock / stub /
> whatever implementation of it, and keep it up to date with API changes to
> the real implementation? If you versioned B appropriately and made A depend
> on a given version of B (to get the correct
> mock/stub/ServiceBEmulator/whatever you want to call it).... that might...
> be... good? somehow? :)
>
> Cheers
>
> - Rory
> (Long time LRUG lurker, very occasional poster)
>
> On 6 Jun 2024, at 12:12, scott at matthewman.net wrote:
>
> I guess when you've got service A calling another service, the unit tests
> for A are really only validly checking for two different things:
>
> 1) That you're passing the expected values to service B depending on
> different scenarios that service A finds itself in
> 2) The service A correctly responds to whatever return values service B
> might pass back, which might include raised exceptions.
>
> If you decouple those two sets of expectations from each other in A's unit
> tests, you're reducing service A's knowledge about how service B works.
>
> When it comes to actually verifying that the calls are valid, that's
> trickier.
> If you're creating doubles to act as stand-ins for real service B, RSpec
> offers you verifying doubles in the shape of class_double and
> instance_double. They only verify that any methods you stub are present on
> the class and don't verify any arguments, though.
>
> Could you establish some sort of factory system in your test suite for
> your doubles, so that you define them all in one place rather than dotted
> throughout your tests? That way, if you make changes to service object B
> you'd get in the habit of updating the doubles at the same time, a syou
> might for, say factory_bot factories when you update. models?
>
> Would be interested to hear thoughts from others…
> On Jun 6, 2024 at 11:56 AM +0100, Patrick Gleeson <
> patrick.c.gleeson at gmail.com>, wrote:
>
> Hi LRUG,
>
> I've been bitten by bad unit tests in the past (mostly ones I've written
> myself), and lean towards integration tests (a la
> https://x.com/rauchg/status/807626710350839808) when given the choice.
> But I want to believe good unit tests are achievable. A problem I often
> encounter is something like this:
>
> 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.
>
> 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?
>
> Patrick
> *Mediocre developer. Failed composer. Fledgeling novelist
> (https://bedfordsquarepublishers.co.uk/book/hattie-brings-the-house-down/
> <https://bedfordsquarepublishers.co.uk/book/hattie-brings-the-house-down/>).*
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20240606/16b28abf/attachment.htm>