yousafn
2018-12-04 22:06
Hey up all,
I am working on a new greenfield application, integrating with some back end services.
I am reasonably familiar with micro-service architecture and consumer driven contract testing.
For around 5 years, I have advocated swagger use for documenting API's, especially in the initial start up phase, as it is always so hard to get people to agree to something concrete, especially in agile teams.
I was recently introduced to PACT a few weeks ago, and instantly bought into the concept. I thought it would be a great asset to our team.
I have built a POC which have received really great feedback.
- It incorporates 4 providing API's and a single consumer. (although for demonstration, I incorporated a 2nd consumer, who hasn't followed the swagger design spec, to show PACT verification failures)
- A pact broker is hosted on an ec2 instance with an rds postgres db
- Consumers are publishing to the pact broker with a version number and git short commit sha `1.0.0-a43d33` and tagging with a branch name
- Consumers are using `@pact-foundation/pact` written in typescript, executed with jest
- Consumers are using `pactfoundation/pact-stub-server` docker with generated pact files, for component integration testing
- Publishers are verifying against the hosted pacts. currently using `1.x.x` style versioning
- Showed the use of can-i-deploy from the console with the pact ruby standalone app, but have mentioned that there are web hooks that can be used to trigger provider verification, when a consumer publishes a new pact.
Things I am having trouble with in PACT (but haven?t investigated yet in the broker code)
- Provider version numbers such as `1.0.0-a43d33` are rejected, I was only able to use <1.0.0>
- branch names such as `feature/ABC-10` are not tagged
Some questions that have been pitched by the client
- Can we get reports that we can send round in an email? The console output from provider verification is well formatted, but only the JSON from the pact-broker looks to be visible. I need to look into report formatters. Devs were pleased to see that we could run the provider verification without publishing results to the broker (so they could get a decent report after a verification has failed)
- it looks like a lot of hard work. - I am sitting on the consumer side, and we have already built it into our pipeline so we are publishing pacts to a broker. It looks to me that on the provider side, their touch points with PACT is light. They don?t need to own or provide their consumer a mock, to allow them to work in insolation. The verification is simply ensuring they have implemented their contract correctly and the clients expectations have been met. There is a point on provider states, but that isn?t PACT specific - we would always want our provider to provide test data & states to stimulate different test cases as in any other api testing framework.
Things I need to investigate
- provider versioning (want to include git short sha)
- branch tagging (want feature/ABC-10 format branches to show up in the broker)
- reporting of verifcation failures in a pretty format
- provider states