https://pact.io logo
Join Slack
Powered by
Here’s a hefty experiment on breaking changes betw...
# pact-js
m
Here’s a hefty experiment on breaking changes between a provider api and consumer api Either the provider introduces backward compatible changes, and ensures all their schema and pact tests are regression free (like @Yousaf Nabi (pactflow.io) tells them to) OR They go through a flow 1. Provider opens a branch with breaking changes, marks it as breaking change in the readme. Even if all is green (unit, e2e, etc), pact tests will fail, UNTIL… 2. The consumer opens a branch with the matching name, AND they update all their code (src, e2e, unit, AND pact) to accommodate. But, EVEN AFTER THAT 3. The Provider has to ensure the new pact tests from the consumer work - and only then they get a green. BUT STILL… 4. The consumer cannot merge until the provider merges. Once the provider gets in the breaking change to main, The consumer can do so too, and they will get a green CI Provider PR Consumer PR
m
Clever, I do like the use of 
PACT_BREAKING_CHANGE
to handle this. It won’t work for all scenarios (in your case, it assumes matching branches if I’m not mistaken) but the principle shows how it can be done 👏
Thanks for sharing all of your lessons and knowledge her Murat, it’s fantastic to see! BTW we are always looking for more contributors and maintainers, if you’re interested let me know - we’d love to have you on board and incorporate some of your fresh ideas into the system
m
thanks that sounds like an idea I want to leave these repos out for consumption, but on the side I want to do them from scratch and perhaps record and publish a paid course - with the motivation of going through it all once again There’s been so much new knowledge and experimentation, things are working at the end but I have to embed it in my head by teaching it. After that, let’s talk
I’ll give you quick ones though with the v4 api, 
builder => builder.jsonBody({..})
is cumbersome you might be able to make the api nicer by currying it like here
Copy code
// Before
 .willRespondWith(200, (builder) => builder.jsonBody({
   id: integer(),
   name: string(name),
   year: integer(year)
 }))

 // After
 .willRespondWith(200, setJsonBody({
   id: integer(),
   name: string(name),
   year: integer(year)
 }))
you might need to come up with something for the other builders like query builder --------- another one I use 
createProviderState
everywhere , makes it fool-proof when passing parameters from the consumer to the provider example ------ I use 
buildVerifierOptions
everywhere, it cleans things up so much, example I’m sure you can revise and improve them to accommodate a wider spectrum. I only solved the inconvenience for my own
m
yep, I can see why you’d want that. In more complicated requests, the reason for that nested builder is to ensure that the prerequisites for certain steps are taken place. There are a lot of bugs that were raised previously that are to do with users calling things in the wrong sequence. The v4 interface aims to correct this with a typed interface preventing it, instead of a lot of code guards to check the state. But this is at the expense of some expressiveness, so helpers like this could be nice
Open in Slack
PreviousNext
Powered by