Hi,
We are in the process of implementing pact fo...
# generala
Ashley Gautama
07/01/2024, 1:46 PMHi,
We are in the process of implementing pact for 2 consumers (ios and andoid). The most asked question is always 'why do we need pacts tests for both OS, they are the same (using the same provider)?' Anybody have a good suggestion to shut down that question quickly?
Ashley Gautama
07/01/2024, 1:49 PMReal reason of the question is of course because they dont want to write the tests
y
Yousaf Nabi (pactflow.io)
07/01/2024, 1:54 PM
are the two consumers a single app that is compiled to different targets, or 2 codebases.
if its two codebases, the argument is pretty simple. only one consumer will have confidence that their needs are being met the provider, and the provider has a harder job because they aren’t consuming contracts for all dependants ( if one consumer codebase doesn’t create pacts)
Yousaf Nabi (pactflow.io)
07/01/2024, 1:56 PM
Real reason of the question is of course because they dont want to write the teststhis might be symptomatic of them not understanding the rationale for these tests and without them, where the issues the technique is seeking to solve, would crop up higher up in the stack.
a
Ashley Gautama
07/01/2024, 1:57 PMits 2 separate code bases ---> so can i translate to 'you might think your needs are being met, since android and ios should have the same implementation, but in actually it might not'?
y
Yousaf Nabi (pactflow.io)
07/01/2024, 1:59 PM
they should have the same implementation is a strong statement, I would probably argue there is a strong possibility that they diverge if they are separate codebases
a
Ashley Gautama
07/01/2024, 2:00 PMI agree with you. The reason they feel this strong is that they look at the same api spec in general around the same timeframe when implementing
Ashley Gautama
07/01/2024, 2:01 PMAnd they are in the same team
y
Yousaf Nabi (pactflow.io)
07/01/2024, 2:01 PM
say you have a biz requirement to show a new field from the providing api, you may add it to the ios app first, then the android app, I doubt you would big bang release them both at the same time.
also the contracts are meant to represent the exact expectations of an api collaborator at a point in time (which is why they are uploaded from CI usually against a commit hash)
https://docs.pact.io/5-minute-getting-started-guide#scope-of-a-consumer-pact-test
Yousaf Nabi (pactflow.io)
07/01/2024, 2:03 PM
if you do it in the same team, its slightly easier to co-ordinate but the onus on someone to co-ordinate and test that. As you would make changes to multiple systems (say update the provider to return a new field, update the 2 consumers to consume that field) you then have to deploy all those apps together and check they work. (and then think about backwards compat, as you may have multiple versions of a mobile app released for a single consumer - which is why pact supports the notion of recording releases, over just deployments)
Yousaf Nabi (pactflow.io)
07/01/2024, 2:04 PM
does either consumer code base have existing tests where they mock out their provider?
These are normally tests where you can drop in replace the mock with a pact client language framework
Yousaf Nabi (pactflow.io)
07/01/2024, 2:05 PM
if they don't have those tests, where are they currently covering it?
a
Ashley Gautama
07/01/2024, 2:05 PMhmm both OS have UI tests going though a 'flow'. For this mock server is used
Ashley Gautama
07/01/2024, 2:08 PManyway the multiple app version is a good argument: there may be cases where 1 app release has been cancelled for a OS. If you only have 1 suite of pact tests you can not handle this 'mismatch'
Ashley Gautama
07/01/2024, 2:08 PMthanks for providing me with ideas
2 Views