 Hi there, so this talk is about integration and contract testing and its potential for API development and maintenance My name is Don Roach. I'm a senior software engineer in American Greetings This light show I'm going to show is going to be on my website, so feel free to pick it up from there and I hope to also like give a link to it from my Twitter and that's my Twitter handle Feel free to go there and follow stuff So okay, so everything starts with story, right? The story is very simple We had this one team that you know was working on a zoo application let's say and So what they were bad monoliths and they said, okay, let's let's let's you know, let's change this we we know we need to We take a different approach for certain reasons who knows But the main thing is that they wanted to go with more with more modern architecture Micro-services, so they separated a separate out these Concerns and then they create these small API's and here there's a zoo API and there's an animal API and So the team had productive meetings. They discussed and nailed down the communication between these services was just requirements They did some documentation. They create these antenna tests to you know cover the you know have us and You know they went on to their merry way So the water life cycle looked like something like this So the land you never came in they sat down read some docs and how to do all their respective API for their team if you're on the zoo API team They'll be working on the zoo API team and they'll read Zoo API documentation And then they'll update the test if you're doing TDD Sometimes that's reverse but So they sort of something to test I write the code and they run the test So all was well Well things that something broke production and you know the zoo app failed as the keepers no longer knew which animals wouldn't brush pens You know tigers, they didn't know even if like how many tigers they had in the pen So that kind of went crazy and they needed to do a rollback of the deployments and you know, they went to a better state So, you know, let's let's go a little bit what happened So so it said like each each application and each API developer would you know, be more concentrated on their API so like Bob from here from zoo API would actually just concentrate on the zoo API He would only update his own test He would update his own code and he would run the test for his API And same thing with John. He worked on the animals API He only read the documents for the animals API and he ran the test for that and go to for that and whatnot So the change they actually found the error found is actually very very simple. Someone changed The status from no to false because it need more sense programmatically, right? Why would you use a no string instead of false string? So So, you know something broke And then they have a retrospective like every good, you know agile team They set down so okay, how can we avoid this in the future? So they talked about some good stuff they did for this, you know That could have avoided this problem and also talk about what can we do a little bit better? So some of the things they talked about is they say, okay, actually do have good documentation, right? We did we have extensive documentation here and then regarding the APIs, right? They had they did specify that they had good documentation for the APIs They said well, I actually write, you know, we write a test for the API So each API would actually have its own unit tests. We just read awesome We like to us and then they did talk about it and tests and they the kind of you know worried because intent tests only covered happy happy hats and there was a reason for that because basically then 10 tests take a long time and I'll get into that a little bit more But you know, that's that's the reason why they kind of limited all their intent tests to the happy hats Because if they include everything would take too much time And they said okay, we have good daily stand-ups, but you know, no one really talked about this change No one really communicated that so it got missed which happens And then some people said hey, we have code reviews. Why wasn't this caught in code views? Well, could use is actually not a tool for communication I mean it is a tool to review your code But it doesn't mean that you're documenting that check change It doesn't mean that you're actually communicating that out There might be someone that might have missed that could review especially large teams across multiple API teams Especially if you started with a solid that may get missed So no one actually caught the change which is you know, which happens So they thought about okay, what might be the possible solutions? So they went over a couple options here. They said, okay, let's write more intent tests I mean it doesn't make sense. I mean you might start right instead of getting only the happy hats You want to actually start you know and getting through these edge cases and writing those but again, you're you're talking about these long Taking Ted's test like they take a long time And I said as before I'll get more information get more into end-to-end tests later and then they said okay Let's do right more documentation. Let's actually you know add more stuff but the thing they notice that is that there actually documentation was almost like 200 pages long and Actually, it was a couple of levels deep So after a while like the a new dog product came in was actually missing some stuff They were actually have to drill down to all these you know Long written long-winded documentation about how an application works and you know things got missed So what still you know, it doesn't mean that they cannot write it clearer, right? So that was come came out retrospective and they said okay, let's do more meetings, right more meetings Definitely helps this all solution to all Well a lot of cries and no, please don't do that. We have enough meetings So that kind of that kind of die down that idea kind of got thrown out of the window So okay, so the question is okay. What what can we do? Well, how can we avoid this problem? And and so whatever solution that comes out Was decided that we need a solution of physical space communication for changes that will affect communication between the services, right? So any if the if the communication between the services changes we need to capture that as soon as possible And and they came up with three bullet points, right? Which should be captured with the solution the first one is misunderstandings from the consumer about endpoints or the payload The second thing is breaking changes from by the provider on the endpoints or payload and bugs in the consumer, right? So these are the three main things that we would like to capture a Solution that will capture only these with minimum effort would faster time time response, right? You don't want to lose too much time in your test. I want to you know fast feedback as soon as possible. So let's see, right? What can that be? so I Want to show you a little bit or you about on each test automation and this is actually belongs to Martin Feller He actually, you know those awesome writings. I definitely suggest you to read them and find them online He has cool stuff So I really like this graph because actually it does summarize the whole tests and what types of tests you can do So there's like unit test is very you know limited to these small components, so like repositories domain and you have your integration tests that actually include you know Some serve, you know, two two or three notes that you'd like to integrate and test, but please do know that Require both of them So you have your component tests. You cannot actually do this all the time You know, especially if your code is highly integrated. It was hard to separate out You know some of these components out, but you know still that's a decent solution to if you're if you wrote your code Let's smartly But then I really and then there's an end-to-end test that is like capturing all of the frame and includes all of these, right? However, your contract tests is like this small portion here, right? So what the contract test does is that it actually verifies Interaction at the boundary of an external service. Okay, so it doesn't require actually the live HDP client to be there It doesn't it's not you don't require a sub client or anything like that So it's pretty nasty In that way, so let's go over our requirements again, right? If it's only on that boundary, you can actually definitely capture misunderstandings from the consumer about end-to-end points and or payload Breaking changes by the provider on end points and payload and bugs in the consumer so actually that that That type of test would actually convert at all. So it's a it's a kind of good solution there I talked about some terminologies here It kind of might cause some confusion. It definitely cost for me when I first read about this So you have a consumer which is a component that initiates a HDP request to another component So it's actually initiator. We're not worried here about what type of methods being used It could be a get a post a put whatever But basically it's initiator of the of the request and then you have a provider A server that responds to an HP request from another component and then you have a contract Which I'm gonna, you know, talk about a little more and the contract is a collection of opinions between a client a consumer and the provider that describes the interactions that take place between them. So Let's okay, let's think about okay, how can we set up a Contract this test now we know some terminologies now We know basically, you know, what the boundaries of this test is going to be and what do we require for that, right? So we have two points right to two steps The first one is defined constructs on consumer expectations saying hey this consumer is going to require Law, you know data and given a main example and verify expectations on the provider Okay So there's a couple tools out there cool tool out there. I definitely I have links at the end that will put out there, but There's a cool tool that's been out there for some time called packs.io And they've been working on a Python version of this That you know is is pre-neat and uh, so big packs.io basically provides a mock service You know, it's a tool that guarantees why basically contracts are satisfied, right? Once you create the contract, you can you know, check that out And enables consumer-driven contract testing and providing mock servers and a DSL You can you know, and I'm gonna go over that a little bit more. So So this is a creating a five contract is actually the same steps that I just mentioned for creating a contract test Basically, you create a test on the consumer side that declares the expectations, right? We talked about expectations here So you'd find those expectations and then you create provider state that allows the contract to pass when replayed a game replayed against a provider Some I have some code examples here. Let's go over that very quickly So There's some code here, but the most important portion of course is this is this line here You're basically defining the the consumer and the provider objects here And so once you just define them you can Actually simply define a pact and and this is the parable DSL portion of this whole whole thing That you can say hey, you know, I have this packed with this given User AA exists and is not an administrator upon receiving a request for user AA With request gets, you know, the user's user a will respond with a 200 and body expected So you define the path the DSL packed here and So it's usually given given to define a setup criteria for the provider and And so basically you can you can actually create reports out of this and and this mock service You know, basically you send up this mock service and you can run your API to gain said it's pretty neat There's more examples in the links on my PowerPoint, which you can later check So But I'm going back to end to end testing. So again, a lot of people ask you will ask, you know, okay I actually have this Actually, I'm testing this right. I'm actually testing the end to end test Well, yes, you probably are testing a lot of the end to end Doing a lot of end to end testing actually maybe covering a lot of these use cases or Problems that might arise. But however, unlike contract, unlike contract, contract testing end to end testing requires all that box in your markup followers Image there actually requires everything there to be online or maybe Set up in some way right and stopped out some way And because that's why it's called end to end testing, right? So it requires a lot of time effort and maintenance to actually go through and set up an end to end test especially environment so So end to end test small also causes small bugs to actually hide behind bigger bugs So if you have an issue, you might not actually find the rest of the issues until you fix the one big issue there out there in the you know in your face And another thing is that intent to assign it are flaky and The thing is this unlike there's a lot of tools that actually make life better, but they're not all perfect So, you know, that's another problem with the end to end testing and it takes as I said before it takes a lot of time to run uh, so there's another tool out there called vcr pi and vcr pi allows you to actually record a You know it responds But the problem with With vcr pi is that you have to actually have both services Up and running, uh, so you have to have a provider You have to have a consumer and you have to actually, you know record those responses and then play replay them back It's pretty nifty. So don't get me wrong. And if you want to go this way, you can use it Uh, but with past actually you can't you don't actually need that consumer or provider to be online and ready You can actually start defining your contract early on and you actually can run your test against that contract So another nice thing about pact is that actually unlike vcr it actually gives you a Given a request for the return, right? There's a there's a nice almost like documentation That you can use and you know make sure you're reused in end So another thing is that you know With what you can actually with pact you can actually start with create these pact brokers that allows you to understand relationship between your microservices and That helps a lot, especially if you have like more than one resource like at least six seven, right after a while It gets kind of crazy. Uh, so this actually allows you to understand what's the relationship between between your microservices which is not available with bcr by And uh, so yeah, so there's things that people are saying. Okay. Hey, I have swagger I have I use open api and uh, I use all the specifications to test my api Well, you remember the first slide where you had two different teams working on their own little test So actually that's what was happening with them, right? They each one created their own little swagger api You know specifications and only tested it against against our own api. They didn't really Test the responses that would be expected or anything like that. Um, I mean, this is so good Definitely, uh, do continue if you're using swagger api. They definitely go Continuing it. Uh, but as I said before, you know, it doesn't actually cover all the problems that you might face Okay, so summary when you get out here, I just want to make sure that you have a couple points And then you you you uh, you remember these, uh, so First of all, if you do contract tests, solve all your problems And maybe if you do contract testing, you don't need any other testing. No, that's that's not it Definitely continue to do unit testing. Definitely do continue to do end-to-end testing Uh, you know each habits has this, you know uses use cases. Uh, however, contract testing is a Basically allows you to do very fast testing against your api or microservice and make sure that you know, uh, contracts are Contracts are satisfied, right making sure that when two teams are working on the same Different microservices, they don't break each other's stuff So, yeah So the benefits again are it's faster than each two end-to-end tests Verifies interactions at the boundary of external service You won't need both the provider and the consumer to be online. So you can actually have a like a quick, uh Into integration and pipeline where one one portion it does an contract test and you have faster feedback And that way, you know, maybe for maybe you can hook this up to a pool request Which is, you know, which might actually take less time. Uh, so And then the thing is this again this contract mentality can actually continue allow you to continue Allow ongoing or facility ongoing communication between solid little teams. So if you have a couple themes out there, uh, you're geographically or maybe because of you know requirements Uh, this this contracts in establishing this contract and sharing this contract from a single source will definitely help out facility that communication and make sure that, you know, people talk to each other. Um So, yeah, that's my time I think So I have some sources here as I said, uh, so these two last links are uh, martin from martin followers You know, uh, website. Definitely check it out. He has awesome information there, uh, and then I put out also, uh, like pacdial, python packed Links and also pat actually has a doctor image that you can just deploy and have his service up and running and Start running your api just against it. Um, thank you for your time And uh, if you want to talk, we can talk later as I know In 20 minutes sessions, we don't have q and a so Thank you very much