[LRUG] Joined-up unit tests

[Rory Sinclair]

Looks interesting, yeah, though it seems to be specifically about HTTP APIs, whereas I was thinking lower-level, like the artefact in question would be a versioned gem, or something.

Just a thought, anyway, not a fleshed-out idea (yet?) :)

Cheers

- Rory


> On 6 Jun 2024, at 13:44, Tom Close <tom.close at cantab.net> wrote:
> 
> 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 <mailto: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 <mailto: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 <mailto: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/).
>>>> 
>>>> _______________________________________________
>>>> Chat mailing list
>>>> Chat at lists.lrug.org <mailto: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 <mailto: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 <mailto: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/e43df8ac/attachment.htm>