Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
Bi-directional contract testing with Yousaf Nabi
182 Plays3 years ago
Conversation with Yousaf about Bi-directional contract testing, who has just started as a developer advocate at Pactflow. In this episode we talk about where should API tests live, the rise of micro-frontends, shift left and much more. If you want to find out more about Pactflow or sign up for free. Also checkout the Tutorials, CI/CD (Consumer Driven Contract Testing) workshop, Bi-Directional Contract Testing Workshop, Pactflow examples
Hosted on Acast. See acast.com/privacy for more information.
Recommended
Transcript
Introduction to API Contract Testing
00:00:00
Speaker
Hello and welcome to how to start API contract testing podcast series with me, Lewis Pacman Prescott, where we'll be talking about the challenges of testing in microservices and how to start API contract testing to make microservice tests faster, more stable, and more realistic. Hello, welcome back to the second episode of the podcast. I had a great conversation with Yousef who has just started as a developer advocate at PacFlow.
00:00:28
Speaker
In this episode, we talk about where should API tests live, the rise of micro front ends, shift left, and much more.
API Test Placement and Micro Front Ends
00:00:35
Speaker
Also, Yusuf talks us through the exciting new bi-directional contracts from PacFlow, which now integrates with tools such as Cypress and Myomock. Before PacFlow, Yusuf has worked for the likes of Skye and Infinityworks.
00:00:48
Speaker
implementing contract testing across multiple different environments. I look forward to talking to him as he is an active member of the contract testing community as well. In this episode, we jump straight into the conversation.
Developers vs Testers: Perspectives on Contract Testing
00:01:00
Speaker
So here we go. From my perspective, I think developers and testers have quite different views on contract testing. And I know you have some thoughts on that as well. Yeah, sure. So yeah, I think contract testing is a really powerful concept.
00:01:15
Speaker
However, Pact requires you to write your contract directly from the source code. That's partly where its value is, it inherently lies. So when we talk about the drift of these mocks, Pact will act as a mock on your consumer side and it will record the interactions that your consumer code actually makes. So you would still
00:01:45
Speaker
work it like a traditional component integration test, but with the added benefit of generating a packed file off the back of it. Now, because you'd run these on each CI build, as your client interface changes and your client code may use more or less fields than the provider sends in its response, it keeps it nicely tightly coupled and avoids drift. A tester traditionally
00:02:15
Speaker
if they work in siloed organizations, can't leverage and generate those packed files because they might not have direct access to the source code. And also, do you want your integration tests to know about the service? Because you're hitting it from the HTTP request, should it know about the service at all? So that's another standpoint. As you
Challenges in Scaling Contract Testing
00:02:38
Speaker
say, those contracts, actually, it would be nice to extract those out.
00:02:43
Speaker
I think you might find that we spoke earlier about doubling up on tests. As testers, we don't want to double up on tests. We may want to try and avoid overlap. We may have existing integration test suites in place that already provide
00:03:02
Speaker
lots of value. When we want to introduce a new testing tool or paradigm or concept, it's sometimes expensive or it takes time and it takes time at the expense of maybe delivering that feature your customer is yearning for. So asking someone to write more pack tests or to be directly involved in the source code where either
00:03:28
Speaker
They're not familiar with that particular source code, but they're familiar with a particular integration testing tool. We can try and leverage the great new features that PackFlow is launching. Why are we trying a different approach with bi-directional contract testing? We've determined that it can be faster to get started, especially when you're plugging it into a retrofit model.
PACT with BFFs and API Gateways
00:03:53
Speaker
Pact is really great. The idea of contract testing is really easy to implement when you're starting a Greenfield service. But ultimately, the whole world of API development isn't that rosy. Sometimes you're having to plug into existing legacy systems.
00:04:15
Speaker
The consumer-driven contract testing model does not necessarily scale to large numbers of consumers. So we found that provider states can sometimes be hard and painful to manage. So we've also seen, well, there is a coupling between the pack tests, the consumer and provider verification in the traditional consumer-driven contract testing model.
00:04:43
Speaker
So we have the notion of provider states in which a consumer could replay the same request, but they could expect a different response. They may expect a 404 response when they request a product because that product isn't available. So on the provider side, that verification takes place by using something called the provider state.
00:05:09
Speaker
We read it in, it's a string value. The provider would manipulate their data repository based on the required state that the consumer has requested. So when you have multiple, you know, a large number of consumers, there can become a large number of provider states in play.
00:05:27
Speaker
One of the reasons we move to microservices is because we want to reduce the dependency and coupling between these services. So introducing provider states and a level of coupling between these builds causes difficulty at scale. There are
New Features for Provider Onboarding
00:05:45
Speaker
particular cases where PACT is not ideally suited and these are well listed on our documentation docs.pact.io.
00:05:55
Speaker
these are BFF or API gateways. So BFF is back end for front end development pattern or API gateways such as GraphQL, AWS, API gateways because these are often pass through or transformation layers. So the problem with these pass through or transformation layers
00:06:17
Speaker
is they don't necessarily handle state themselves. They interact with another service. During provider verification, we don't get a strong guarantees or we have to build in a dependency in that provider verification with the other services it calls.
00:06:38
Speaker
We've seen the rise of micro front ends and UI testing with PACT has led to pain. With the PACT and PACT Flow team being really in tune with their community, they thought they'd introduce this new model in order to make it easier for provider teams to get on board with PACT.
00:07:02
Speaker
So we highlighted that the biggest pain in the consumer-driven contract testing world was provider verification. So we wanted to make it as easy as possible for the providers to get on board. We advocate for open API spec, or formerly
Integrating Testing Workflows with Adapters
00:07:19
Speaker
known as swagger files, to document those APIs. Pactflow has now provided a mechanism
00:07:26
Speaker
for you to upload your open API spec to the packed flow system. This is known as a provider contract. Alongside uploading your open API spec, the provider would run a testing tool such as Postman, Dread, or Rest assured to functionally test their API to ensure that it is in sync with their open API specification.
00:07:55
Speaker
they can upload that verification result and open API spec to the packed flow platform. At this point, the provider is able to call the can I deploy tool. So the can I deploy tool is a nifty automatic gated check that will check a provider and consumers relationships
00:08:21
Speaker
with regard to the particular environment that a provider or consumer wishes to deploy into. So the provider would have an open API spec uploaded to the packed flow platform. A consumer would generate a consumer contract in the form of a packed file. The consumer can do this via the traditional mechanism.
00:08:45
Speaker
They can do it via one of the many packed implementations in multiple languages, such as Java, JavaScript, Go, Ruby, et cetera. Or the team over at packed flow started to release adapters for common integration tools.
00:09:03
Speaker
We currently have an adapter for Wiremock, Cypress, and a mock service worker. These adapters have been designed to very easily plug into your integration test workflows and will record and generate packed files from your existing integration test.
00:09:23
Speaker
These packed
Utilizing Existing Tests in Startups
00:09:24
Speaker
files can then be uploaded to the packed flow platform. At the point of calling, can I deploy on the consumer side, the packed flow platform will provide cross-contract verification between the consumer packed file and the provider open API specification.
00:09:44
Speaker
Yeah, I think this is huge because as you say and what we've been talking about is you're going to have all these existing tests. Why can't we just leverage those? And also coming from a startup world, I mean, we get to a point where developers are not even writing unit tests because they don't have time to develop the software that needs to be delivered. So any way that we can enable them to cut a corner or reduce that learning curve is a big win.
00:10:12
Speaker
going back to the conversation that we're having between developers and testers. I think this is another bridge that will enable testers now to speak the same language and say, okay, we've got this open API spec and I'm using Cypress to test it. Win-win.
00:10:28
Speaker
I think for me it's a huge win. We might always have proponents of a particular tool that advocate for a particular testing tool or have a fondness. I know I've had many kind of conversations around Cyprus versus Selenium.
00:10:47
Speaker
However, a tester would always say it depends. You pick the right tool for the right job, and you're always going to use a set of tools that complement each other. You don't use any particular one tool, and that is your go-to thing for everything.
00:11:06
Speaker
understanding how these different tools can leverage and play together in an ecosystem in order to enable and strengthen developers in what they're doing can only be valuable. So some
Expanding Contract Testing Adoption
00:11:23
Speaker
of the main objectives of the bidirectional contract testing is really to reduce the time to value for contract testing.
00:11:32
Speaker
We markedly want to simplify the adoption and scaling of contract testing. And we'd really like to expand and breadth the technology of that we can support things like GraphQL, Protobuffs. We'd like to expand the different types of ways that the contract can be generated.
00:11:53
Speaker
So we spoke about some of those bring your own tools, such as Cypress, Mock Service Worker, and Wiremock. If the community would like to see or build more tools, we'd love to be happy to engage and support that. One of my A names at PacFlow is enabling the development community.
00:12:15
Speaker
So over the kind of nine years that PACT has been open source, we've had over 450 contributors who've helped make it the success it is today. As it's grown, it has grown in complexity. I think you can probably hark back to some onboardings you've had at previous organisations and your minds are blur.
00:12:37
Speaker
for the first few weeks. So anything we can do to simplify the message of contract testing, but also to simplify the journey when it comes to viewing the PAC documentation.
00:12:54
Speaker
to finding what you need when you need it, but also providing nice tools for developers who wish to contribute, be it small or big, and that might be providing signposting to our public roadmap. It might be providing really nice developer experiences so that if you want to run the code base locally in order to do some local development, we can enable that.
00:13:21
Speaker
cool
Collaborative Contract Testing and Communication Benefits
00:13:22
Speaker
sounds really really exciting times and yeah absolutely the more people that we can get involved for the better i think and yeah absolutely the the bi-directional contracts for me answers one of the big questions that i always get whenever i bring up is why do we need packed
00:13:39
Speaker
as well, because we've already got our open API specs, or we already use open API, or we already have JSON schema up front, so we know what format it's going to be in. We've got that pre-agreed. So I think this solves that question as well. Now I can say you can use those. We're going to use those, but now we're going to call it contract testing. So yeah, it's really cool.
00:14:01
Speaker
Yeah, I think for me, the big win is as a provider generating a service, you provide an open API spec. It tells the world how your service is going to behave, but it doesn't necessarily tell you how consumers are exactly using your service.
00:14:19
Speaker
Oh, for sure. Yeah. And it changes over time, right? It's generated. So even if you're defining upfront, development changes, like you discover things as you're developing. So it's going to change over time. So that's exactly where we need these mechanisms to come in. As I always endorse going forwards is it's a communication tool as well.
00:14:40
Speaker
Definitely. It's not just a tool to enable you to improve your development. It's a tool to have more conversations with your consumers, because you need to have those, as you say, to set up the provider state. So it's a collaboration tool. And going back to what you said earlier about why you enjoy your role is that collaboration. And I think that is
00:15:01
Speaker
at the heart of what contract testing is. Agreed. I definitely think from
Exploring Bidirectional Contracts and Community Engagement
00:15:06
Speaker
the term consumer-driven contract testing, we maybe should change that to collaborative contract testing. And I think we will see a shift between the word collaborative, especially when we talk about shift left mentality. You're completely bang on the money with the fact that it actually opens up conversations that happen anyway, but it opens them up sooner, much sooner.
00:15:30
Speaker
this particular integration testing problem can be solved and we can concentrate on other things that are really important. Yeah, absolutely. Thanks for that, Yusuf. Really interesting and can't wait to play around with some of the adapters with bidirectional contracts. Where can we find out more about this stuff?
00:15:52
Speaker
In terms of signposting, if you are interested, you should come join us in the PACT Slack community at slack.pact.io. Or you can check out our website at docs.pactflow.io, where you can check out some of our great university tutorials and examples where you can see the bidirectional flows in action and test them out on your machine. We'd love to hear your feedback on the new feature. And if there's anything more that you'd wish to see, give us a shout.
00:16:23
Speaker
Yeah, good stuff. All the links and stuff will be in the show notes, so they'll be all there for you to take a look. Yeah, definitely check out the tutorials and stuff. They're really, really easy to follow and get involved. So yeah, thanks for coming on. You stuff. Really appreciate it.
00:16:45
Speaker
No, thank you for being such an amazing champion of the patch community and we look forward to working with you more in the future, my friend. Thank you. Cheers. Cheers.