1 00:00:00,080 --> 00:00:04,440 We talk about this a lot in the book, but the communication is 2 00:00:04,440 --> 00:00:07,840 the key to this, and contract testing facilitates that. 3 00:00:08,039 --> 00:00:10,800 It's that communication facilitator while you're 4 00:00:10,800 --> 00:00:12,760 developing software, things can change. 5 00:00:13,040 --> 00:00:17,760 It's very easy for humans to make mistakes, and so that's 6 00:00:17,760 --> 00:00:22,040 where contract testing kind of comes in, is we're saying that 7 00:00:22,240 --> 00:00:25,880 we know things are going to change, and so we want to 8 00:00:26,000 --> 00:00:29,640 capture that and help people debug those issues because 9 00:00:29,640 --> 00:00:33,160 breaking changes can be difficult to identify. 10 00:00:33,560 --> 00:00:38,120 One of the main ones is that faster feedback because you're 11 00:00:38,120 --> 00:00:41,920 not relying on an environment and you can point to the 12 00:00:41,920 --> 00:00:45,640 contracts that are potentially not even live yet in an 13 00:00:45,640 --> 00:00:50,600 environment and you have control over your own code base. 14 00:00:50,640 --> 00:00:54,200 So getting that fast feedback early is a huge benefit. 15 00:00:54,440 --> 00:00:57,240 But you should definitely have more contract tests than 16 00:00:57,240 --> 00:01:01,360 integration and end to end. But it's not to say that it 17 00:01:01,360 --> 00:01:04,319 replaces those. So you still need integration 18 00:01:04,319 --> 00:01:10,000 tests for your configuration for some of your business logic. 19 00:01:23,290 --> 00:01:25,530 Hello everyone, welcome back to another new episode of the 20 00:01:25,530 --> 00:01:28,610 Technical General Podcast. Today I have with me the author 21 00:01:28,610 --> 00:01:32,160 of Contract Testing in Action. It's still in early manning 22 00:01:32,160 --> 00:01:34,360 release, right? But I think we can talk about 23 00:01:34,360 --> 00:01:37,720 the contract testing today. So if you're into testing and 24 00:01:37,720 --> 00:01:40,280 testing techniques, I think today we'll learn about this 25 00:01:40,280 --> 00:01:43,680 technique, which is kind of like getting some tractions because 26 00:01:43,680 --> 00:01:47,200 of the micro service trend. And Louis Prescott is here with 27 00:01:47,200 --> 00:01:48,640 me. So thank you so much for your 28 00:01:48,640 --> 00:01:51,040 time and looking forward to learn from you about this 29 00:01:51,040 --> 00:01:54,000 contract testing. Thank you so much for having me, 30 00:01:54,120 --> 00:01:56,320 so pleasure to be here. Right. 31 00:01:56,400 --> 00:01:59,680 So Louise, I always love in the beginning to ask my guests to 32 00:01:59,680 --> 00:02:02,000 probably share more a little bit about yourself. 33 00:02:02,000 --> 00:02:04,480 So if you can, mention any highlights or turning points 34 00:02:04,480 --> 00:02:06,000 that you think we can learn from you. 35 00:02:06,760 --> 00:02:09,720 Yeah, of course. So yeah, I started out, I did a 36 00:02:09,720 --> 00:02:15,920 degree in psychology and then I stumbled upon working in 37 00:02:15,920 --> 00:02:21,040 software for a small business that worked on like psychometric 38 00:02:21,040 --> 00:02:24,200 profiling, so analysing people's behaviours. 39 00:02:24,520 --> 00:02:26,640 And obviously they had the software that went along with 40 00:02:26,640 --> 00:02:28,880 that. I worked out that the software 41 00:02:28,880 --> 00:02:33,720 side of things was really interesting and obviously the 42 00:02:33,720 --> 00:02:37,080 software testing. And from there I joined a 43 00:02:37,080 --> 00:02:42,000 graduate scheme with a testing consultancy who trained me up 44 00:02:42,240 --> 00:02:46,240 and gave me the foundations that I still use today. 45 00:02:46,240 --> 00:02:49,240 So that was a real big turning point for me, right? 46 00:02:49,440 --> 00:02:52,920 Complete career change to what I thought I was going to be doing. 47 00:02:53,560 --> 00:02:57,360 And then that's really helped me kind of push through my career. 48 00:02:57,360 --> 00:03:01,720 Worked in lots of managerial roles within testing, learnt to 49 00:03:01,720 --> 00:03:05,720 code on the job as part of the consultancy, which was 50 00:03:05,720 --> 00:03:07,880 completely foreign to me when I started. 51 00:03:07,880 --> 00:03:11,480 And I, yeah, it took me a long time to get to where I am today. 52 00:03:12,080 --> 00:03:15,560 And then, yeah, I've worked for some really great businesses, so 53 00:03:15,880 --> 00:03:20,440 some start-ups and also a company called ASOS, the online 54 00:03:20,480 --> 00:03:24,360 retailer works in a really great environment there, kind of cross 55 00:03:24,360 --> 00:03:26,920 functional teams, very forward thinking. 56 00:03:27,240 --> 00:03:31,040 And then worked in the healthcare space for a long time 57 00:03:31,400 --> 00:03:37,040 and I've recently joined IBM and I now work on the NHS app as a 58 00:03:37,040 --> 00:03:41,200 test specialist on there. So yeah, lots of variety of my 59 00:03:41,360 --> 00:03:44,920 journey, but yeah, kind of consistently in testing. 60 00:03:45,640 --> 00:03:46,960 Thank you for sharing your story. 61 00:03:46,960 --> 00:03:50,120 So one thing if I may follow up right from what you shared 62 00:03:50,120 --> 00:03:52,120 earlier. So in the beginning you started 63 00:03:52,120 --> 00:03:56,560 studying psychology and you even work on a system that work for 64 00:03:56,560 --> 00:03:59,760 psychometric test. So just wondering how do you 65 00:03:59,760 --> 00:04:01,480 actually test this kind of system? 66 00:04:01,480 --> 00:04:05,280 Because I mean like the input is mainly human behaviors and 67 00:04:05,280 --> 00:04:07,320 they're answers and how do you assess the output? 68 00:04:08,120 --> 00:04:11,800 Yeah, of course. So all of the assessments are 69 00:04:11,800 --> 00:04:16,480 based on research. So all of them are validated and 70 00:04:16,480 --> 00:04:20,880 verified based on their like personality profiles. 71 00:04:21,440 --> 00:04:24,440 I can't remember the name of them at the moment, but like the 72 00:04:24,480 --> 00:04:29,760 kind of well researched, well backed ones and then the 73 00:04:29,760 --> 00:04:33,640 software side of things with purely people being able to 74 00:04:33,640 --> 00:04:37,400 access the form and being able to enter the results. 75 00:04:37,680 --> 00:04:41,240 I wasn't doing any of the like interpretation or any of the 76 00:04:41,240 --> 00:04:43,840 research, just purely the software side of things. 77 00:04:44,640 --> 00:04:46,520 Right. So I could imagine it might be 78 00:04:46,680 --> 00:04:49,320 quite difficult to actually assess whether the accuracy of 79 00:04:49,320 --> 00:04:52,600 the calculation or the categorisation, right. 80 00:04:52,600 --> 00:04:55,520 So I think that must be a challenge altogether. 81 00:04:55,640 --> 00:04:57,240 Leave that to the professional issue. 82 00:04:57,680 --> 00:04:59,760 Right. So today we'll be talking about 83 00:04:59,760 --> 00:05:02,000 contract testing. So you're writing this book at 84 00:05:02,000 --> 00:05:04,800 the moment, right? So in the 1st place, maybe many 85 00:05:04,800 --> 00:05:07,560 people might have heard about contract testing or might not 86 00:05:07,560 --> 00:05:09,080 have heard about contract testing. 87 00:05:09,320 --> 00:05:12,680 I personally have heard about it, but haven't actually seen it 88 00:05:12,680 --> 00:05:14,600 in action in any projects that I have. 89 00:05:14,840 --> 00:05:18,480 So in the 1st place, maybe tell us why contract testing exists, 90 00:05:18,480 --> 00:05:20,480 what kind of problems that it tries to solve. 91 00:05:21,480 --> 00:05:25,880 Yeah, absolutely to my journey was started learning about 92 00:05:25,880 --> 00:05:30,240 contract testing, completely foreign concept, really like 93 00:05:30,240 --> 00:05:34,080 found it hard to get my head around it until you realise what 94 00:05:34,080 --> 00:05:37,560 the problems it solves. Obviously most of the people 95 00:05:37,560 --> 00:05:41,800 that come to concept testing have familiarity with API 96 00:05:41,800 --> 00:05:45,200 testing, integration testing, that kind of background. 97 00:05:45,560 --> 00:05:51,680 And so those tests are quite unstable, rely on test 98 00:05:51,680 --> 00:05:55,440 environments to be available, integrations to be configured, 99 00:05:55,680 --> 00:06:01,680 and all those kind of factors contribute to those tests, be it 100 00:06:01,680 --> 00:06:04,440 flaky or taking a long time to run. 101 00:06:04,760 --> 00:06:08,600 So that's one of the areas where contract testing comes in. 102 00:06:09,000 --> 00:06:14,800 Another kind of area is breaking changes to your API, knowing who 103 00:06:15,120 --> 00:06:19,000 is consuming your API, how they're consuming it, what 104 00:06:19,160 --> 00:06:24,840 changes are going to break that contract, and generally building 105 00:06:24,840 --> 00:06:28,440 software in a way which is backwards compatible, so having 106 00:06:28,440 --> 00:06:31,240 that confidence to deliver that software going forwards. 107 00:06:31,680 --> 00:06:36,000 So contract testing comes in and it kind of solves that because 108 00:06:36,000 --> 00:06:40,200 it gives you fast feedback, it gives you the versioning of your 109 00:06:40,200 --> 00:06:44,400 APIs through the contracts. And yeah, we'll go into more 110 00:06:44,400 --> 00:06:47,560 detail about what contract testing is and stuff, but yeah, 111 00:06:47,840 --> 00:06:50,960 they're the kind of main areas where it really helps you in 112 00:06:50,960 --> 00:06:52,560 that software delivery life cycle. 113 00:06:53,360 --> 00:06:54,760 Right. I, I could imagine last time 114 00:06:54,760 --> 00:06:57,120 when I, we used to work a lot with service oriented 115 00:06:57,120 --> 00:06:58,960 architecture on micro services, right? 116 00:06:58,960 --> 00:07:01,440 So I mean, in the beginning, maybe it's easy when you have 117 00:07:01,440 --> 00:07:05,240 one to one relationship where you have producer and consumer 118 00:07:05,600 --> 00:07:07,640 and any change you can just communicate, right. 119 00:07:07,920 --> 00:07:10,760 But I guess since the era of micro services and 120 00:07:10,760 --> 00:07:14,080 interconnectedness with, you know, so many SAS applications 121 00:07:14,080 --> 00:07:17,000 or maybe API is available out there, right, You start to have 122 00:07:17,000 --> 00:07:19,320 this permutations of possibilities of API 123 00:07:19,320 --> 00:07:21,480 integrations. And I think one of the challenge 124 00:07:21,480 --> 00:07:23,640 that you mentioned, right is breaking change. 125 00:07:24,040 --> 00:07:27,880 Initially, I think we all just rely on the contract, maybe open 126 00:07:27,880 --> 00:07:30,800 API spec that you just distribute around or you just 127 00:07:31,000 --> 00:07:33,280 tell somebody, hey, we are going to change this and you need to 128 00:07:33,280 --> 00:07:36,440 change that. So I think all these definitely 129 00:07:36,440 --> 00:07:39,640 is one of the problems that we foresee when you have a lot of 130 00:07:39,640 --> 00:07:42,360 API integrations. So tell us a little bit more how 131 00:07:42,360 --> 00:07:45,080 contract testing is being utilized maybe in this kind of 132 00:07:45,080 --> 00:07:47,560 era of micro services? Yeah. 133 00:07:47,560 --> 00:07:52,000 So microservice is definitely like the biggest use case for 134 00:07:52,000 --> 00:07:53,600 it. Obviously, the more the 135 00:07:53,600 --> 00:07:58,480 complexity goes up and the more integrations you have, then 136 00:07:58,760 --> 00:08:00,880 obviously you want to scale those things. 137 00:08:01,000 --> 00:08:05,760 And so contract testing comes in and effectively the most similar 138 00:08:05,760 --> 00:08:09,840 comparison is when you're using a mock to mock out your 139 00:08:09,840 --> 00:08:12,280 integrations. That's where contract testing 140 00:08:12,280 --> 00:08:16,720 comes in and it says, OK, you're interacting with the service in 141 00:08:16,720 --> 00:08:19,440 this way. That forms part of the contract 142 00:08:19,760 --> 00:08:24,320 and this is what you expect to get back from that service in 143 00:08:24,320 --> 00:08:28,200 order to render that on the page or store that information in the 144 00:08:28,200 --> 00:08:31,800 database. So the contract is formed from 145 00:08:31,800 --> 00:08:36,000 the request and the response and that forms that contract. 146 00:08:36,159 --> 00:08:40,480 The web application or the mobile application then 147 00:08:40,600 --> 00:08:44,000 generates that contract and puts it in a central place. 148 00:08:44,000 --> 00:08:48,720 So using the tool packed, it's stored in a packed broker. 149 00:08:49,080 --> 00:08:54,040 And then the person who creates the API or is the author or 150 00:08:54,040 --> 00:08:58,240 whatever the owner, they then replay that contract on their 151 00:08:58,240 --> 00:09:01,160 side. So it's about forming all of 152 00:09:01,160 --> 00:09:04,280 those different contracts with all of the different scenarios 153 00:09:04,280 --> 00:09:08,920 that you interact with that integration point, for example, 154 00:09:09,080 --> 00:09:13,680 error scenarios, different query programs, all those kind of 155 00:09:13,680 --> 00:09:17,080 interactions and putting those into contracts and then getting 156 00:09:17,080 --> 00:09:21,640 the the provider, the person, the owner to replay those 157 00:09:21,640 --> 00:09:25,080 contracts. So yeah, it's passing around 158 00:09:25,400 --> 00:09:30,640 contracts which have those expected results in basically. 159 00:09:31,360 --> 00:09:33,000 You said something about mock, right? 160 00:09:33,000 --> 00:09:35,840 So I think if I get it correctly, right, So we are 161 00:09:35,840 --> 00:09:39,880 actually not testing the actual service that you are calling or 162 00:09:39,880 --> 00:09:42,120 maybe you are returning back to, right? 163 00:09:42,360 --> 00:09:45,760 So you're actually utilizing mock and something like a replay 164 00:09:45,760 --> 00:09:49,520 kind of mechanism where you send a particular request and you 165 00:09:49,520 --> 00:09:51,760 expect some kind of a response back. 166 00:09:52,120 --> 00:09:56,160 So I think 1 area as well that I learned from what you just said, 167 00:09:56,160 --> 00:09:57,560 right? There are many kind of 168 00:09:57,560 --> 00:10:00,440 components that exist in a contract testing. 169 00:10:00,440 --> 00:10:03,600 You mentioned something about central place or broker, so 170 00:10:03,600 --> 00:10:06,360 maybe tell us a little bit more like what are these components 171 00:10:06,360 --> 00:10:09,920 that exist in a contract testing so that we get familiar a little 172 00:10:09,920 --> 00:10:12,880 bit more about it? Yeah, absolutely. 173 00:10:13,120 --> 00:10:18,440 So the terminology we use in contract testing is you have a 174 00:10:18,440 --> 00:10:22,160 consumer, so that's your web app, your mobile app, and as a 175 00:10:22,160 --> 00:10:28,760 service that's your consumer. The provider is the API or the 176 00:10:28,760 --> 00:10:34,400 event mechanism that generates those events, and then they are 177 00:10:34,400 --> 00:10:36,520 to provide them. Then you have to store the 178 00:10:36,520 --> 00:10:38,280 contracts. So where you're going to store 179 00:10:38,280 --> 00:10:42,160 them, that's called the broker. That's where they're all stored. 180 00:10:42,480 --> 00:10:47,080 And then there's another component because as you 181 00:10:47,080 --> 00:10:50,480 mentioned, the services aren't communicating with each other, 182 00:10:50,480 --> 00:10:52,320 they're just communicating via a contract. 183 00:10:52,640 --> 00:10:57,400 So then there's the CLI tool which allows you to query the 184 00:10:57,400 --> 00:11:01,120 broker to say, has this contract BeenVerified? 185 00:11:01,640 --> 00:11:05,440 And within the packed world that's called can I deploy? 186 00:11:05,800 --> 00:11:09,120 So yeah, it's just a way of querying it and saying, does 187 00:11:09,120 --> 00:11:12,680 this contract has it's BeenVerified by both parties, 188 00:11:13,200 --> 00:11:15,680 OK, we can release. So they're the kind of four 189 00:11:15,680 --> 00:11:17,200 components. Right. 190 00:11:17,440 --> 00:11:20,040 Just to recap a bit. So there's a consumer, so which 191 00:11:20,040 --> 00:11:23,200 is the one who consumes the API, right, The providers, the one 192 00:11:23,200 --> 00:11:27,080 who will produce the API that says broker where you store the 193 00:11:27,080 --> 00:11:28,520 contracts. Of course, there's a contract 194 00:11:28,520 --> 00:11:32,000 itself there, the component, the Great Expectations between both 195 00:11:32,000 --> 00:11:33,760 parties. And then the last one, you 196 00:11:33,760 --> 00:11:36,720 mentioned there's ACLI tool that we can utilize to query the 197 00:11:36,720 --> 00:11:40,720 broker to check about the contract and the expectations 198 00:11:40,720 --> 00:11:44,600 and all that, I guess. So I think in your definition in 199 00:11:44,600 --> 00:11:47,120 the book, you also mentioned something that I think is quite 200 00:11:47,120 --> 00:11:48,840 interesting to highlight here, right? 201 00:11:48,840 --> 00:11:52,120 So contract testing is actually a form of testing where you are 202 00:11:52,120 --> 00:11:55,760 verifying 2 systems have actually the same shared 203 00:11:55,800 --> 00:11:58,200 understanding about the expectations. 204 00:11:58,560 --> 00:12:01,520 So tell us why this is important to have the shared 205 00:12:01,560 --> 00:12:03,880 understanding. I think in the requirements 206 00:12:03,880 --> 00:12:06,080 world it is. I've also mentioned a lot about 207 00:12:06,160 --> 00:12:09,040 shared expectations, you know, from the business and also the 208 00:12:09,040 --> 00:12:11,880 technology team, right? How does this share 209 00:12:11,880 --> 00:12:14,400 understanding also play a part in the contract testing? 210 00:12:15,160 --> 00:12:17,280 Yeah. So it's, it's, it's super 211 00:12:17,280 --> 00:12:20,480 important, right, when you're dealing with multiple teams, 212 00:12:20,480 --> 00:12:25,040 distributed teams remotely, all that kind of thing that we share 213 00:12:25,480 --> 00:12:29,680 the source of truth and also why you're developing software. 214 00:12:29,680 --> 00:12:32,080 Things can change as you're developing. 215 00:12:32,080 --> 00:12:36,360 So the way that we mentioned about generating contracts is 216 00:12:36,360 --> 00:12:41,760 via an open API specification, which is potentially generated 217 00:12:42,120 --> 00:12:46,160 after the code is built. Or you could mock it up before 218 00:12:46,160 --> 00:12:48,560 the development starts and share that around. 219 00:12:48,960 --> 00:12:50,760 How do you share that around, right? 220 00:12:50,800 --> 00:12:55,440 You share it in a wiki page or you share it in a central 221 00:12:55,440 --> 00:12:58,520 location where in a GitHub repository or something like 222 00:12:58,520 --> 00:13:00,880 that. All these things require human 223 00:13:00,880 --> 00:13:04,000 intervention, right? It's all, I've changed the 224 00:13:04,000 --> 00:13:05,840 contract. I need to remember to 225 00:13:06,080 --> 00:13:11,240 communicate that I need to update it in the wiki and all 226 00:13:11,240 --> 00:13:14,720 these kind of things. Like it's very easy for say, 227 00:13:14,720 --> 00:13:18,240 humans to make mistakes. And so that's where contract 228 00:13:18,240 --> 00:13:22,840 testing kind of comes in is we're saying that we know things 229 00:13:22,840 --> 00:13:26,960 are going to change. We know that the specifications 230 00:13:26,960 --> 00:13:31,000 might change over time. And so we want to capture that 231 00:13:31,000 --> 00:13:34,680 and help people debug those issues because breaking changes 232 00:13:34,680 --> 00:13:39,520 can be difficult to identify. And you may have lots of 233 00:13:39,520 --> 00:13:43,760 consumers and they will use different pieces of the API and 234 00:13:43,760 --> 00:13:47,840 stuff like that. So that sharing of that contract 235 00:13:48,520 --> 00:13:51,160 is super important to enable this. 236 00:13:51,760 --> 00:13:56,680 And then the other scenario, right, is you have teams that 237 00:13:56,680 --> 00:13:59,560 are working on two different code bases, front end of the 238 00:13:59,560 --> 00:14:04,640 back end and they're writing in two different languages, they're 239 00:14:04,880 --> 00:14:06,800 developing at exactly the same time. 240 00:14:07,280 --> 00:14:11,520 So like the rapid changes that are happening, you want that 241 00:14:11,520 --> 00:14:14,400 shared understanding to continue over time. 242 00:14:14,400 --> 00:14:18,240 And so yeah, creating that central place to store it, to 243 00:14:18,520 --> 00:14:20,920 enable you to version it and everything like that. 244 00:14:21,320 --> 00:14:22,840 That hopefully answer your question. 245 00:14:23,520 --> 00:14:26,200 Yeah, certainly. So I think thanks for explaining 246 00:14:26,200 --> 00:14:28,560 that, right? Because it's very important to 247 00:14:28,560 --> 00:14:31,120 realise about this shared understanding because I think 248 00:14:31,120 --> 00:14:33,680 maybe one to one again, it's quite simple, right? 249 00:14:33,680 --> 00:14:36,600 You can just back and forth converse or this is my 250 00:14:36,600 --> 00:14:39,280 expectations, this is the behaviour and this is the 251 00:14:39,280 --> 00:14:42,880 response of the output, right. But once you have when you start 252 00:14:42,880 --> 00:14:46,120 to have a permutations like for example, even multiple versions 253 00:14:46,160 --> 00:14:48,920 of the APIs, right, the evolution of the APIs, the 254 00:14:48,920 --> 00:14:51,720 backward compatibility. And then once you start having 255 00:14:51,720 --> 00:14:54,360 more and more consumers, this is where it gets tricky, right? 256 00:14:54,360 --> 00:14:58,400 Because you will not be able to trace all the changes that 257 00:14:58,400 --> 00:15:01,240 happens and how it will impact those teams, right? 258 00:15:01,240 --> 00:15:04,200 Or those consumers. So I think contract testing 259 00:15:04,200 --> 00:15:07,600 definitely is very interesting. So for people now who understand 260 00:15:07,600 --> 00:15:11,160 a little bit about contract testing, so tell us maybe some 261 00:15:11,160 --> 00:15:14,240 of the benefits that maybe you have seen in the real world 262 00:15:14,240 --> 00:15:16,680 where you actually implemented contract testing. 263 00:15:16,960 --> 00:15:20,360 So what are some of the obvious benefits that you can share so 264 00:15:20,360 --> 00:15:23,640 that people can understand exactly what kind of value they 265 00:15:23,640 --> 00:15:26,440 will get out of this? Yeah, absolutely. 266 00:15:26,520 --> 00:15:31,760 And one of the main ones is that faster feedback because you're 267 00:15:31,760 --> 00:15:36,360 not relying on an environment. You can point to the contracts 268 00:15:36,360 --> 00:15:40,760 that are potentially not even live yet in an environment, and 269 00:15:40,800 --> 00:15:44,440 you have control over your own code base, right? 270 00:15:44,440 --> 00:15:47,040 The consumer generates contracts from their side. 271 00:15:47,320 --> 00:15:51,760 The provider spins up their local environment or however 272 00:15:51,760 --> 00:15:55,240 they choose to do it to run the contract tests. 273 00:15:55,240 --> 00:15:58,840 So getting that fast feedback early is a huge benefit. 274 00:15:59,360 --> 00:16:03,480 And independently, right, In that scenario, there's no 275 00:16:03,480 --> 00:16:05,800 dependencies, but you control everything. 276 00:16:06,040 --> 00:16:10,240 The caveat to that obviously is the provider needs to have their 277 00:16:10,240 --> 00:16:15,120 data and you set up their data in some way or a mechanism for 278 00:16:15,120 --> 00:16:18,080 doing that. And then that may come with 279 00:16:18,080 --> 00:16:20,480 complexities. But yeah, so that fast feedback 280 00:16:20,480 --> 00:16:22,880 loop catching those issues earlier. 281 00:16:23,040 --> 00:16:27,040 So not waiting for the changes to go into that integration 282 00:16:27,040 --> 00:16:30,600 environment, which can be potentially later on in your 283 00:16:30,600 --> 00:16:33,760 cycle. And one I mentioned earlier, 284 00:16:33,760 --> 00:16:38,800 right, about the ability to debug those issues, it can be 285 00:16:39,000 --> 00:16:42,400 difficult when you run your integration test because you're 286 00:16:42,400 --> 00:16:46,680 pointing at it from the outside. You get a response back, which 287 00:16:46,680 --> 00:16:52,720 is a 500 or a 400, and it just says bad request. 288 00:16:52,720 --> 00:16:56,840 And you're like, well, I don't know what that is, what's wrong 289 00:16:56,840 --> 00:16:58,720 with my request, that kind of thing. 290 00:16:58,720 --> 00:17:02,640 So like having that contract in place makes it super easy to 291 00:17:02,960 --> 00:17:06,200 replay those on both sides. So, yeah. 292 00:17:06,280 --> 00:17:12,520 And another huge benefit of this flipping of integration testing 293 00:17:12,520 --> 00:17:16,920 to the consumer is it's consumer driven, right? 294 00:17:17,040 --> 00:17:22,680 And that means that the users in this scenario, because they're 295 00:17:22,680 --> 00:17:26,800 the users of the API, are the ones creating the tests, right? 296 00:17:26,800 --> 00:17:32,480 So in terms of being as lifelike and as close to production as 297 00:17:32,480 --> 00:17:36,640 you can get, then these sit nicely in there and give that 298 00:17:36,640 --> 00:17:39,720 consumer view of how the API is being used. 299 00:17:40,240 --> 00:17:42,760 So there are a few benefits that you get. 300 00:17:44,680 --> 00:17:46,960 Yeah. So I would also imagine that you 301 00:17:46,960 --> 00:17:51,280 can deploy things in a much independent way and confidently 302 00:17:51,280 --> 00:17:53,680 as well, right? Because before you actually go 303 00:17:53,680 --> 00:17:56,680 to production, you would have verified all the interactions 304 00:17:56,680 --> 00:17:59,080 that you have with either your consumer providers, right? 305 00:17:59,080 --> 00:18:03,280 You would have verified that all can actually work still, right? 306 00:18:03,520 --> 00:18:05,240 And that's this tool. Can I deploy? 307 00:18:05,240 --> 00:18:07,880 It's like a fancy term, right? Can I deploy? 308 00:18:07,880 --> 00:18:10,600 And then when it's green, then you can safely assume that 309 00:18:10,600 --> 00:18:13,720 everything will just work as it is compared to the previous way 310 00:18:13,760 --> 00:18:17,280 of working where you have tested everything like your unit test, 311 00:18:17,280 --> 00:18:20,080 integration test, E to E test, all working fine. 312 00:18:20,080 --> 00:18:22,480 But then once you deploy to production, right, it's always 313 00:18:22,480 --> 00:18:25,920 the case where something broken because the integration actually 314 00:18:25,920 --> 00:18:28,480 changed the behavior and then you have to quickly rollback. 315 00:18:28,720 --> 00:18:30,880 Yeah. So I think this is very 316 00:18:30,880 --> 00:18:33,160 interesting. I just mentioned about unit 317 00:18:33,160 --> 00:18:35,160 test, integration test, and E to E test. 318 00:18:35,160 --> 00:18:38,040 So there's this testing pyramid concept, right, in the testing 319 00:18:38,040 --> 00:18:40,440 world. So what do you think? 320 00:18:40,440 --> 00:18:45,000 Where does contact testing actually reside in that pyramid, 321 00:18:45,000 --> 00:18:46,560 right? Is it unit test, is it 322 00:18:46,560 --> 00:18:48,640 integration test or is it E to E test? 323 00:18:49,520 --> 00:18:52,880 Yeah, it's a great point. And like contract testing kind 324 00:18:52,880 --> 00:18:57,400 of sits next to the unit test. So when you're generating your 325 00:18:57,400 --> 00:19:01,520 contracts on the consumer side, it sits next to the function 326 00:19:01,520 --> 00:19:04,600 that makes that request because it needs to intercept that 327 00:19:04,600 --> 00:19:07,600 request. And then on the provider side, 328 00:19:07,760 --> 00:19:12,000 it's a bit more like integration level because it pulls down that 329 00:19:12,000 --> 00:19:16,440 contract and replays it on their side so that you have a running 330 00:19:16,440 --> 00:19:19,080 service. So it's kind of a mixture of 331 00:19:19,080 --> 00:19:21,760 unit and integration. So in the pyramid, it kind of 332 00:19:21,760 --> 00:19:26,040 sits in that just below integration tests and just above 333 00:19:26,040 --> 00:19:29,240 unit. So yeah, again, it sits nicely 334 00:19:29,240 --> 00:19:33,840 in that way in that you have more control and you get that 335 00:19:33,840 --> 00:19:36,840 fast feedback a bit further down the pyramid. 336 00:19:37,520 --> 00:19:40,560 So I think it's in the same spirit of a pyramid, right. 337 00:19:40,840 --> 00:19:44,960 So do you think we should have more contract testing versus 338 00:19:44,960 --> 00:19:49,360 more integration or E to E test or like tell us about this shape 339 00:19:49,360 --> 00:19:52,400 or ratio of number of tests? Yeah. 340 00:19:52,400 --> 00:19:55,400 So you should definitely have more contract tests than 341 00:19:55,400 --> 00:20:00,200 integration and end to end, but it's not to say that it replaces 342 00:20:00,200 --> 00:20:02,520 those. So you still need integration 343 00:20:02,520 --> 00:20:08,680 tests for your configuration for some of your business logic of 344 00:20:09,200 --> 00:20:14,360 this API needs to be available at this performance level and 345 00:20:14,360 --> 00:20:19,160 stuff like that. The contract is testing the 346 00:20:19,720 --> 00:20:24,240 request and response. And it's not testing the exact 347 00:20:24,240 --> 00:20:28,000 values that come back, right. So like there's still lots of 348 00:20:28,000 --> 00:20:32,400 unit tests that you need and there's lots of integration or 349 00:20:32,400 --> 00:20:35,200 not lots, some integration that you need. 350 00:20:35,200 --> 00:20:38,680 So it's definitely more, you can fit more scenarios in that 351 00:20:38,680 --> 00:20:42,480 contract level where it talks about the error scenarios, the 352 00:20:42,480 --> 00:20:44,760 different query parameters that you're passing. 353 00:20:45,080 --> 00:20:47,560 So there's lots of different scenarios that can fit into 354 00:20:47,560 --> 00:20:51,760 there and then you still need some of your integration and end 355 00:20:51,760 --> 00:20:53,160 to end. Yeah. 356 00:20:53,160 --> 00:20:55,520 I just want to highlight one more time what you said, right? 357 00:20:55,520 --> 00:20:58,760 So this doesn't replace integration or E to E test, 358 00:20:58,760 --> 00:21:01,080 right? And one thing also important to 359 00:21:01,080 --> 00:21:04,440 note, the contract testing doesn't verify the business 360 00:21:04,440 --> 00:21:07,960 logic or the correctness of the output or the value, right? 361 00:21:08,160 --> 00:21:11,040 So those things should probably be more in the unit test or 362 00:21:11,040 --> 00:21:14,840 maybe integration or the E to E And also it doesn't test all the 363 00:21:14,840 --> 00:21:17,840 other maybe quality attributes like performance, maybe 364 00:21:17,840 --> 00:21:19,920 security, whatever that is, right? 365 00:21:20,240 --> 00:21:23,480 So please take note about that. And I think I'm sure some people 366 00:21:23,640 --> 00:21:26,560 would have tried, you know, like a verifying correctness of the 367 00:21:26,560 --> 00:21:28,480 behavior in the contract testing as well. 368 00:21:28,920 --> 00:21:32,560 So one thing about contract testing that I also learnt from 369 00:21:32,560 --> 00:21:34,880 your book, right? You mentioned that for API 370 00:21:34,880 --> 00:21:38,600 providers that have public consumers, you know, like you 371 00:21:38,600 --> 00:21:42,400 don't know actually how many the consumers of the API or maybe 372 00:21:42,480 --> 00:21:44,800 third party, external third party that you don't have 373 00:21:44,800 --> 00:21:47,360 control over. Contract testing probably is not 374 00:21:47,360 --> 00:21:49,360 suitable for those kind of scenarios. 375 00:21:49,520 --> 00:21:51,880 So tell us a little bit more about this, why that is the 376 00:21:51,880 --> 00:21:53,520 case. Yeah. 377 00:21:53,520 --> 00:21:57,600 So as I mentioned, the consumer driven approach. 378 00:21:57,680 --> 00:22:01,960 So what we've been discussing so far is the kind of consumer 379 00:22:01,960 --> 00:22:06,240 driven way. And so the person who creates 380 00:22:06,240 --> 00:22:11,960 those contracts is the consumer. And so obviously in the public 381 00:22:12,120 --> 00:22:16,760 and the kind of third party integration scenario, you don't 382 00:22:16,760 --> 00:22:20,560 have that input and you can't drive it that way, especially 383 00:22:20,560 --> 00:22:23,160 with the public way, right. Like you don't want it driven by 384 00:22:23,160 --> 00:22:25,760 the consumer, otherwise you'd have an endless tack log of 385 00:22:25,760 --> 00:22:28,120 things like it would just get insane. 386 00:22:28,520 --> 00:22:30,840 Yeah. So from a consumer driven 387 00:22:30,840 --> 00:22:33,600 perspective, it's not necessarily the right choice, 388 00:22:34,280 --> 00:22:37,320 but there's still value in in contract testing. 389 00:22:37,320 --> 00:22:41,680 It just sits in a a slightly different flow which there are 390 00:22:41,680 --> 00:22:44,600 solutions for. It's just not in this consumer 391 00:22:44,600 --> 00:22:46,760 driven methodology. Yeah. 392 00:22:46,760 --> 00:22:49,720 So you have mentioned a few Times Now consumer driven, 393 00:22:49,720 --> 00:22:52,040 consumer driven, right. So I think many people would 394 00:22:52,040 --> 00:22:55,080 probably be puzzled, right, Like what is this consumer driven 395 00:22:55,080 --> 00:22:56,920 like? Maybe now is a good time to 396 00:22:56,920 --> 00:22:59,520 actually introduce how many different types of contract 397 00:22:59,520 --> 00:23:02,720 testing are actually out there. Yeah, there's quite a few 398 00:23:02,720 --> 00:23:05,760 different types. And it's also good to call out 399 00:23:05,800 --> 00:23:11,040 that there are other people coining contract testing, but 400 00:23:11,240 --> 00:23:16,160 they are doing it at a slightly different level and it can be 401 00:23:16,160 --> 00:23:20,320 confused with like schema based testing, which does that kind of 402 00:23:20,320 --> 00:23:24,560 static level stuff. So yeah, it is quite confusing 403 00:23:24,560 --> 00:23:28,160 and it can get quite blurry along with a lot of other terms 404 00:23:28,560 --> 00:23:32,160 in the testing space as well. But yeah, there's two main types 405 00:23:32,160 --> 00:23:36,120 in terms of what is offered by Pact and pack flow. 406 00:23:36,560 --> 00:23:40,720 So consumer driven, whether the consumer creates the contracts, 407 00:23:40,720 --> 00:23:44,480 the provider that verifies them. And then there's what we coined 408 00:23:44,480 --> 00:23:47,880 in the book, Provider driven contract testing, which is also 409 00:23:47,880 --> 00:23:51,480 known as bidirectional because you can kind of do a combination 410 00:23:51,480 --> 00:23:54,000 of both. But yeah, the provider driven 411 00:23:54,000 --> 00:23:58,720 approach is kind of more catered to those public API kind of 412 00:23:58,720 --> 00:24:05,680 scenarios where the API can generate contracts, verify their 413 00:24:05,680 --> 00:24:10,080 own contracts. So open API specifications, they 414 00:24:10,080 --> 00:24:14,720 verify those with their own testing framework and then they 415 00:24:14,720 --> 00:24:19,440 can publish those results to the broker and then the consumer can 416 00:24:19,440 --> 00:24:22,760 then verify those against their own contracts. 417 00:24:23,040 --> 00:24:26,680 So the provider doesn't have to do any additional work and 418 00:24:26,680 --> 00:24:29,800 replay anything on their side. They're just saying here is our 419 00:24:29,800 --> 00:24:33,040 contract, we've verified everything in here is true. 420 00:24:33,520 --> 00:24:38,200 And you can also verify it via the pack broker, but that's only 421 00:24:38,200 --> 00:24:42,280 available on pack Flow, which is the software as a service 422 00:24:42,280 --> 00:24:45,520 version. And the team there who are many 423 00:24:45,520 --> 00:24:49,920 of whom created packed and are part of that, they also have 424 00:24:49,920 --> 00:24:53,440 this pack Flow which stores your contracts and does obviously 425 00:24:53,440 --> 00:24:56,200 much more functionality. It's like bidirectional. 426 00:24:57,000 --> 00:24:58,800 Right. It seems like in your book you 427 00:24:58,800 --> 00:25:02,440 explain that the provider driven contract testing, right, is 428 00:25:02,440 --> 00:25:06,120 suitable for those who start to learn about contract testing or 429 00:25:06,120 --> 00:25:08,680 they come from the legacy of, I don't know, like things like 430 00:25:08,680 --> 00:25:13,000 open API where you have the spec already and you just publish it 431 00:25:13,000 --> 00:25:16,240 to broker and then consumer can kind of like verify it against 432 00:25:16,240 --> 00:25:18,520 the broker, whether the behavior is the same. 433 00:25:18,880 --> 00:25:20,800 And you mentioned about pack and pack flow. 434 00:25:20,800 --> 00:25:24,160 Pack itself is like probably the most well known contract testing 435 00:25:24,160 --> 00:25:25,800 tool or framework out there, right? 436 00:25:25,800 --> 00:25:29,040 The pack flow is like the SAS, the product on top of pack, 437 00:25:29,480 --> 00:25:32,560 right for people who are doing this provider driven contract 438 00:25:32,560 --> 00:25:35,320 test. So maybe after knowing about 439 00:25:35,320 --> 00:25:38,600 these two type, I think the first traditional one is 440 00:25:38,600 --> 00:25:40,440 actually the consumer driven one, right. 441 00:25:40,680 --> 00:25:45,800 So obviously many people would have a challenge in visualizing 442 00:25:45,800 --> 00:25:49,320 how is the workflow like because you have a consumer, you have a 443 00:25:49,320 --> 00:25:51,240 producer, you have a broker in between, right? 444 00:25:51,400 --> 00:25:53,240 And both sides also make changes. 445 00:25:53,560 --> 00:25:56,840 How is the workflow like and maybe in the typical CICD 446 00:25:56,880 --> 00:26:00,240 pipeline manner, maybe if you can just illustrate a little bit 447 00:26:00,440 --> 00:26:03,560 so that people also understand like how would they work with 448 00:26:03,560 --> 00:26:06,480 this contract testing? Yeah, absolutely. 449 00:26:06,520 --> 00:26:10,320 And the key is what we're talking about, right? 450 00:26:10,320 --> 00:26:14,400 It's deploying with confidence. So there's kind of three or four 451 00:26:14,400 --> 00:26:18,960 steps to get to that point. So the consumer generates the 452 00:26:18,960 --> 00:26:21,440 contracts, publishes those to the broker. 453 00:26:21,960 --> 00:26:26,160 The provider then pulls down those contracts, verifies those 454 00:26:26,600 --> 00:26:31,840 against the latest version or whatever version is going to be 455 00:26:31,840 --> 00:26:36,040 released, and then it goes back to the consumer. 456 00:26:36,400 --> 00:26:42,000 So then the consumer will use the can I deploy tool to make 457 00:26:42,000 --> 00:26:46,080 that check to say, OK, I'm going to release this new version of 458 00:26:46,080 --> 00:26:49,520 the contract. The provider has verified it. 459 00:26:49,880 --> 00:26:54,160 Can I deploy to an environment to production? 460 00:26:54,680 --> 00:26:58,200 And so they're the core steps that you would have in CI. 461 00:26:58,680 --> 00:27:01,800 So they would sit into separate places, right? 462 00:27:01,800 --> 00:27:05,360 So the consumer, on the consumer side, they would have their 463 00:27:05,640 --> 00:27:10,200 contract generation tag it with this, the version that they're 464 00:27:10,200 --> 00:27:12,440 going to release and then publish it. 465 00:27:13,080 --> 00:27:16,640 Then the next step they would have in their pipeline is the 466 00:27:17,240 --> 00:27:22,680 can I deploy to say, OK, I want to release this now, can I 467 00:27:22,680 --> 00:27:24,720 deploy that? And then they tag that with the 468 00:27:24,720 --> 00:27:27,480 specific environment that they're going to deploy it to 469 00:27:28,000 --> 00:27:30,280 and the specific version that's going to be deployed. 470 00:27:30,720 --> 00:27:34,840 And then on the provider side of things, they would obviously 471 00:27:34,840 --> 00:27:39,640 have their tests that run in CI which verify that specific 472 00:27:39,640 --> 00:27:42,280 version and publish those results. 473 00:27:42,680 --> 00:27:47,160 So they would only be publishing those in CI to make sure that 474 00:27:47,280 --> 00:27:49,400 it's not sitting on a branch or anything like that. 475 00:27:49,720 --> 00:27:54,040 So they tag it then with the version of the API which is 476 00:27:54,320 --> 00:27:58,680 they're pointing to and the environment that that is 477 00:27:58,680 --> 00:28:02,000 available in. And so from the provider side, 478 00:28:02,160 --> 00:28:07,520 that's it from ACI perspective, unless they also have consumers, 479 00:28:07,640 --> 00:28:11,360 right, which they may have if they're a service that shares 480 00:28:11,360 --> 00:28:14,240 data two ways. And so then they would also have 481 00:28:14,240 --> 00:28:16,040 a Canon deploy step. Yeah. 482 00:28:16,160 --> 00:28:18,760 So that's the kind of cycle of things. 483 00:28:18,760 --> 00:28:21,240 So then obviously once the consumer's ready, they will 484 00:28:21,240 --> 00:28:25,080 deploy that to production and everything will be tagged and 485 00:28:25,120 --> 00:28:26,400 ready. Right. 486 00:28:26,600 --> 00:28:29,800 So I can visualise it a bit, right, The workflow, I have some 487 00:28:29,800 --> 00:28:32,800 follow up questions because again, like this is probably new 488 00:28:32,800 --> 00:28:34,840 to some people as well. The 1st is about the can I 489 00:28:34,840 --> 00:28:37,280 deploy, right? Because there's this gap between 490 00:28:37,440 --> 00:28:39,960 the consumer generating the contract and publishing it to 491 00:28:39,960 --> 00:28:43,280 the broker and actually for the provider to actually run their 492 00:28:43,280 --> 00:28:46,280 tests and verify and update the broker. 493 00:28:46,560 --> 00:28:49,720 So I guess in the consumer CI pipeline, right? 494 00:28:49,840 --> 00:28:52,760 Does it just wait or continuously pull, you know, 495 00:28:52,760 --> 00:28:54,280 like, can I deploy, can I deploy? 496 00:28:54,600 --> 00:28:58,040 Or like what's the trigger like to actually proceed to the next 497 00:28:58,040 --> 00:29:00,440 stage of the pipeline, right? Because you might have, you 498 00:29:00,440 --> 00:29:03,400 know, integration tests, E to E tests and all those things that 499 00:29:03,400 --> 00:29:05,480 are also waiting. Yeah. 500 00:29:05,480 --> 00:29:10,320 Usually you'd have two separate pipelines, right, One which is 501 00:29:10,800 --> 00:29:13,920 building and then the other one which is deploying. 502 00:29:14,360 --> 00:29:17,680 So it would usually be split across those two things. 503 00:29:18,080 --> 00:29:22,840 Obviously if the two are connected together, then you'll 504 00:29:22,840 --> 00:29:26,640 be running that step of the same pipeline just later on, right. 505 00:29:27,080 --> 00:29:33,480 And So what is clever about the pack broker is if the provider 506 00:29:33,800 --> 00:29:39,200 hasn't theirs is compatible with previous versions, then that 507 00:29:39,200 --> 00:29:42,840 consumer can still deploy because it's BeenVerified 508 00:29:42,840 --> 00:29:46,240 against the previous version and there's been no changes which is 509 00:29:46,240 --> 00:29:51,200 going to affect that deployment. So it can then say, OK, I've got 510 00:29:51,200 --> 00:29:55,640 this one three versions ago and nothing's changed since then. 511 00:29:55,640 --> 00:30:01,040 So you can still deploy this or the responses are the same based 512 00:30:01,040 --> 00:30:05,480 on different factors. So you can still deploy with in 513 00:30:05,480 --> 00:30:09,760 that scenario, but obviously if there's a new version then the 514 00:30:10,280 --> 00:30:14,520 can I deploy tool will just return a response to say this 515 00:30:14,520 --> 00:30:18,760 has not BeenVerified and then you would need to trigger the 516 00:30:18,760 --> 00:30:21,840 other pipeline. But that's easily done, right? 517 00:30:21,840 --> 00:30:26,520 If you're working in a CICD environment, then you can easily 518 00:30:26,520 --> 00:30:30,480 trigger another pipeline from yours to get those verifier 519 00:30:30,480 --> 00:30:34,040 tests to run or communication, right. 520 00:30:34,120 --> 00:30:38,880 Like we talk about this a lot in the book, but the communication 521 00:30:38,880 --> 00:30:42,920 is the key to this, the problem and contract testing facilitates 522 00:30:42,920 --> 00:30:44,880 that. If you get the communication 523 00:30:44,880 --> 00:30:48,960 right, you don't need constant testing because everything works 524 00:30:49,400 --> 00:30:53,400 and you don't have any issues about fricking changes or 525 00:30:53,400 --> 00:30:55,400 anything. But it's that communication 526 00:30:55,400 --> 00:30:59,320 facilitator. So that's where, yeah, in CICD, 527 00:30:59,320 --> 00:31:03,880 if it hasn't been verified yet or if it fails, then you can 528 00:31:03,880 --> 00:31:06,920 jump on a call with that team and start discussing it. 529 00:31:07,280 --> 00:31:12,040 So there's obviously a delay and getting that information, but 530 00:31:12,400 --> 00:31:14,680 you should be able to move pretty quickly. 531 00:31:15,520 --> 00:31:17,640 So thanks for highlighting about the communication and the 532 00:31:17,640 --> 00:31:19,480 agreement, right, between those two teams. 533 00:31:19,480 --> 00:31:22,560 So having contract testing doesn't mean that both parties 534 00:31:22,560 --> 00:31:26,440 just don't talk to each other and just rely on whatever tools 535 00:31:26,440 --> 00:31:28,200 that exist, right? So I think communication is 536 00:31:28,200 --> 00:31:30,000 still the key. Again, the key point here is 537 00:31:30,040 --> 00:31:31,720 about share understanding, right? 538 00:31:32,000 --> 00:31:35,000 And you would probably not get shared understanding if you 539 00:31:35,000 --> 00:31:37,800 don't talk to each other. So I think human aspects of the 540 00:31:38,120 --> 00:31:39,600 software development is still key. 541 00:31:40,120 --> 00:31:42,640 So I think that is one question that I have. 542 00:31:42,640 --> 00:31:45,880 So the CI, I would imagine that you can proceed with the rest of 543 00:31:45,880 --> 00:31:48,720 the stages of the pipeline, but somehow before you deploy the 544 00:31:48,720 --> 00:31:50,280 production, you have to join with this. 545 00:31:50,280 --> 00:31:54,440 Can I deploy parallel track to actually be confident about your 546 00:31:54,440 --> 00:31:57,040 change as well? So the other aspect is that the 547 00:31:57,040 --> 00:31:59,640 provider side as well, right? Because now if let's say you 548 00:31:59,640 --> 00:32:03,360 have to support multiple consumers, I would imagine that 549 00:32:03,360 --> 00:32:07,720 your pipeline will get triggered by multiple consumers updating 550 00:32:07,720 --> 00:32:09,360 their contracts. Is that the case? 551 00:32:09,360 --> 00:32:13,280 Or like how does the producer actually work by having all 552 00:32:13,280 --> 00:32:15,600 these contracts that they need to serve and verify? 553 00:32:16,480 --> 00:32:18,520 Yeah, yeah. It's essentially that could be 554 00:32:18,520 --> 00:32:21,840 the case, absolutely. But as we discussed earlier 555 00:32:21,840 --> 00:32:26,200 about it all being isolated and working independently, right, 556 00:32:26,200 --> 00:32:29,360 there shouldn't be any dependencies and obviously that 557 00:32:29,360 --> 00:32:32,880 pipeline gets queued behind another one, then the 558 00:32:32,880 --> 00:32:36,640 verification process will still have occurred, right? 559 00:32:36,640 --> 00:32:40,240 So shouldn't delay anything on the motor for consumer side of 560 00:32:40,240 --> 00:32:42,720 things. But the area that I mentioned 561 00:32:42,720 --> 00:32:46,160 earlier as well about the data side of things, right? 562 00:32:46,160 --> 00:32:49,280 So from a proprietor's perspective, the heavy duty 563 00:32:49,360 --> 00:32:53,560 lifting is the consumer may be sending you lots of scenarios 564 00:32:53,560 --> 00:32:57,400 where the data needs to be in this state and you've got a 565 00:32:57,400 --> 00:32:59,000 hundred of those scenarios, right? 566 00:32:59,320 --> 00:33:03,360 And that's one of the big hurdles in terms of contract 567 00:33:03,360 --> 00:33:06,960 testing because you have to be able to set up that data as part 568 00:33:06,960 --> 00:33:10,720 of your test. And that's a limited factor 569 00:33:10,720 --> 00:33:12,720 really. Obviously there's a way around 570 00:33:12,720 --> 00:33:15,960 that with sharding your database and things like that. 571 00:33:15,960 --> 00:33:19,120 But like, obviously that that requires development time and, 572 00:33:19,480 --> 00:33:22,560 and there's complexities to it. So yeah, the provider's 573 00:33:22,560 --> 00:33:26,360 definitely going to be doing the heavy lifting in that respect 574 00:33:26,800 --> 00:33:30,800 and the pipeline will have to accommodate for that. 575 00:33:31,600 --> 00:33:34,600 Yeah, just by having a better understanding about the workflow 576 00:33:34,600 --> 00:33:36,600 now, right? I can actually imagine this can 577 00:33:36,600 --> 00:33:39,840 be quite tricky to implement, especially if those two teams 578 00:33:39,840 --> 00:33:41,520 are not like close to each other, right? 579 00:33:41,520 --> 00:33:45,120 Let's say they're different departments, they don't use to 580 00:33:45,120 --> 00:33:48,800 work together. So if let's say only one site 581 00:33:48,800 --> 00:33:52,160 wants to implement this, but they cannot convince either the 582 00:33:52,160 --> 00:33:55,160 producer or consumer to also do the same, will this still work? 583 00:33:55,320 --> 00:33:58,360 Or do you think getting the buy in is something that is very 584 00:33:58,360 --> 00:34:01,080 important before you actually embark on this contract testing? 585 00:34:01,840 --> 00:34:05,720 Yeah, the buy in is potentially the hardest part of this whole 586 00:34:06,080 --> 00:34:09,440 journey and we talked about that a lot in the first few chapters 587 00:34:09,440 --> 00:34:13,520 of the book is what we're selling as part of this 588 00:34:13,520 --> 00:34:15,840 contract. Testing in action is not 589 00:34:15,840 --> 00:34:20,120 necessarily just the technical side of things because that is 590 00:34:20,120 --> 00:34:23,719 only part of it. And lots of people will say I've 591 00:34:23,719 --> 00:34:27,840 already got an integration test suite or we already test our 592 00:34:27,840 --> 00:34:30,600 schemas using schema testing tool. 593 00:34:30,960 --> 00:34:34,760 So there's only a narrow window of stuff that we need to cover 594 00:34:34,760 --> 00:34:38,920 that's currently not covered and that's absolutely fine view, 595 00:34:38,920 --> 00:34:41,360 right? It's just if you want to seek 596 00:34:41,360 --> 00:34:45,159 the benefits that we discussed earlier on, then that's where 597 00:34:45,280 --> 00:34:47,679 you'll want to implement contract testing. 598 00:34:48,199 --> 00:34:52,600 And the problem is that usually teams embark on this journey 599 00:34:53,000 --> 00:34:56,000 after they've already got these suites of things. 600 00:34:56,000 --> 00:35:01,000 So yeah, that upfront selling and getting on board early on 601 00:35:01,240 --> 00:35:03,280 definitely facilitates that process. 602 00:35:03,760 --> 00:35:07,600 And then if you start to hit these hurdles later on, then you 603 00:35:07,600 --> 00:35:10,280 can start implementing bidirectional provider driven 604 00:35:10,280 --> 00:35:14,280 approach which will enable you to convert your integration 605 00:35:14,280 --> 00:35:19,600 tests to contract tests. The selling again is part of you 606 00:35:19,600 --> 00:35:22,200 need a broker, right? So you need someone to pay for 607 00:35:22,200 --> 00:35:25,400 that or someone to host that. Obviously there's an open source 608 00:35:25,400 --> 00:35:29,160 version which you can host yourselves, but that still has 609 00:35:29,160 --> 00:35:32,800 running costs, so you've got to be able to sell it. 610 00:35:32,800 --> 00:35:36,800 And so that's why we spend so much time in the first couple of 611 00:35:36,800 --> 00:35:40,960 chapters talking about what the benefits are, what problems 612 00:35:40,960 --> 00:35:45,880 we're going to solve for that, and what the solution looks like 613 00:35:45,880 --> 00:35:49,320 in terms of that life cycle of the CICD. 614 00:35:49,320 --> 00:35:53,040 So you can work out, OK, will this fit into our delivery life 615 00:35:53,040 --> 00:35:55,880 cycle and will this solve the problems that we're currently 616 00:35:55,880 --> 00:35:58,560 having. So yeah, the selling is 617 00:35:58,560 --> 00:36:01,800 definitely a big part of that. In your view, who should own the 618 00:36:01,800 --> 00:36:04,000 broker, right? Because then you have consumer, 619 00:36:04,000 --> 00:36:06,240 you have provider like who should own it actually. 620 00:36:07,240 --> 00:36:10,800 Yeah, it's a great question. I mean, it usually falls under 621 00:36:10,800 --> 00:36:14,080 DevOps, right? Like that kind of team will 622 00:36:14,080 --> 00:36:16,920 usually host it. If you've got a open source 623 00:36:16,920 --> 00:36:20,760 version or if you pay for the software as a service station 624 00:36:20,760 --> 00:36:25,320 with pack flow, then it really doesn't matter who's owning it. 625 00:36:25,360 --> 00:36:27,080 It just comes out of some of the budget. 626 00:36:27,360 --> 00:36:29,920 And obviously because it's going to be shared across multiple 627 00:36:29,920 --> 00:36:33,600 consumers, it will probably be leadership or someone in the 628 00:36:33,600 --> 00:36:37,360 management will be signing off on it because it will sit across 629 00:36:37,360 --> 00:36:41,520 multiple teams. So yeah, but what I say to 630 00:36:41,520 --> 00:36:46,280 people in terms of that question is until you start using it and 631 00:36:46,280 --> 00:36:50,480 like start seeing the benefits of it, then you're never going 632 00:36:50,480 --> 00:36:53,760 to get started, right? So like, even if you have 5 633 00:36:53,760 --> 00:36:57,080 brokers to start with, because you've all set up your own ones 634 00:36:57,320 --> 00:37:00,400 and then you can consolidate them at a later date, like 635 00:37:00,400 --> 00:37:03,320 you've got to get started because otherwise you'll just be 636 00:37:03,320 --> 00:37:05,960 sat there thinking like, what benefit are you going to get out 637 00:37:05,960 --> 00:37:08,240 of this? And also the concept as well, 638 00:37:08,240 --> 00:37:12,400 the concept's hard to understand how it work in practice until 639 00:37:12,400 --> 00:37:14,040 you actually get a proof concept. 640 00:37:14,040 --> 00:37:17,240 So yeah, it's a really good question of one get asked a lot, 641 00:37:17,560 --> 00:37:21,200 but yeah, just get started. So for people who wants to get 642 00:37:21,200 --> 00:37:23,800 started, I know you have mentioned a lot about PAC. 643 00:37:24,000 --> 00:37:26,600 Is PAC the right tool to get started or are there other 644 00:37:26,600 --> 00:37:28,560 alternatives out there if I'm wrong? 645 00:37:28,560 --> 00:37:31,040 I've heard something about like mounted bank before. 646 00:37:31,280 --> 00:37:33,680 I don't know whether that's a contract testing tool, but like 647 00:37:33,800 --> 00:37:36,640 tell us maybe what are some of the tools we can explore? 648 00:37:36,760 --> 00:37:40,280 Or is PAC actually the de facto standard that we should try to 649 00:37:40,280 --> 00:37:43,600 use in the very beginning? Yes, it's a really great 650 00:37:43,600 --> 00:37:47,120 question. So Pact is like the go to in 651 00:37:47,120 --> 00:37:51,040 terms of it has lots of different language supports and 652 00:37:51,400 --> 00:37:55,520 has a core like Ruby base. So they all just build off of 653 00:37:55,520 --> 00:37:58,120 that. And so that's definitely the one 654 00:37:58,120 --> 00:38:00,360 that I would start with if you're looking for one. 655 00:38:00,640 --> 00:38:04,400 But yeah, there's lots of other places which offer some form of 656 00:38:04,640 --> 00:38:08,920 contract testing, like Postman has a version and Mount Mac 657 00:38:08,920 --> 00:38:10,360 might have a version, I'm not sure. 658 00:38:10,800 --> 00:38:15,160 Hacked has got an adapter for the mock, so it can definitely 659 00:38:15,160 --> 00:38:17,320 facilitate that. And then you've got like Source 660 00:38:17,320 --> 00:38:21,800 Labs, Test Sigma, all these now have contract testing solutions. 661 00:38:22,120 --> 00:38:25,520 I read the small print about what it's actually doing behind 662 00:38:25,520 --> 00:38:28,520 the scenes. But yeah, and The thing is, you 663 00:38:28,520 --> 00:38:33,160 don't actually need at all. You could do this with a GitHub 664 00:38:33,160 --> 00:38:39,240 folder, or you could do this locally in a local folder where 665 00:38:39,240 --> 00:38:43,840 you verify your request and your expectations against the 666 00:38:43,840 --> 00:38:46,640 providers. You just need somewhere to share 667 00:38:46,640 --> 00:38:48,280 it. So you don't actually 668 00:38:48,280 --> 00:38:52,680 necessarily need a tool. Obviously the tool provides lots 669 00:38:52,680 --> 00:38:56,760 of shortcuts and it's been doing it for a long time, so it's got 670 00:38:56,760 --> 00:39:00,440 lots of functionality built in to facilitate that process. 671 00:39:00,840 --> 00:39:04,200 But the actual concept of contract testing is just the 672 00:39:04,200 --> 00:39:05,880 concept. You could implement it 673 00:39:05,880 --> 00:39:08,840 yourselves. You could use any of the tools 674 00:39:08,840 --> 00:39:11,680 that are available to you. It's just time. 675 00:39:12,200 --> 00:39:13,640 And communication for sure, right? 676 00:39:13,640 --> 00:39:15,880 So don't forget. So you can use all the tools, 677 00:39:15,880 --> 00:39:18,560 but if you don't communicate, I guess it's not optimal as well. 678 00:39:18,880 --> 00:39:21,920 So I could imagine, yeah, I mean, pack probably will help in 679 00:39:21,920 --> 00:39:24,120 terms of workflow and automation, right, for some of 680 00:39:24,120 --> 00:39:26,240 those steps. But I would imagine you can also 681 00:39:26,240 --> 00:39:28,280 do it manually, although, yes, it's a bit tricky. 682 00:39:28,280 --> 00:39:31,560 You need to coordinate and you have to put the things into the 683 00:39:31,560 --> 00:39:34,120 right place and triggers your pipeline and things like that. 684 00:39:34,400 --> 00:39:36,200 So I think definitely for people. 685 00:39:36,200 --> 00:39:38,840 Thanks for the tips, right? Maybe pack is something that you 686 00:39:38,840 --> 00:39:41,560 should explore. And I think pack also support 687 00:39:41,560 --> 00:39:43,480 some of the advanced use cases, right? 688 00:39:43,480 --> 00:39:46,040 So you mentioned in your book something like can I deploy 689 00:39:46,520 --> 00:39:49,360 maybe web hook, right? And also about this versioning. 690 00:39:49,560 --> 00:39:52,840 So tell us a little bit more what kind of versioning support 691 00:39:52,840 --> 00:39:55,600 that maybe pack supports and why is it important? 692 00:39:56,440 --> 00:39:59,520 Yes, we discussed this bit earlier when we're talking about 693 00:39:59,520 --> 00:40:04,040 that life cycle view of when you're deploying it, what 694 00:40:04,040 --> 00:40:05,520 environment you're deploying it to. 695 00:40:06,240 --> 00:40:09,480 And all that kind of thing. So obviously whenever you 696 00:40:09,480 --> 00:40:13,480 generate a new contract, that generates a new version, and 697 00:40:13,480 --> 00:40:17,040 whenever the provider verifies it, that verifies against that 698 00:40:17,040 --> 00:40:19,520 version. And if a provider makes changes, 699 00:40:19,840 --> 00:40:22,120 then they will update their version as well. 700 00:40:22,440 --> 00:40:25,840 So all the versions are stored within the contract. 701 00:40:26,120 --> 00:40:30,800 So you wouldn't necessarily be changing your version of your 702 00:40:30,800 --> 00:40:33,840 API if you don't have version in built in. 703 00:40:34,320 --> 00:40:37,200 And on the consumer side of things, you don't generally have 704 00:40:37,200 --> 00:40:41,040 a version for I'm changing my interactions. 705 00:40:41,080 --> 00:40:44,800 You just have, I'm releasing a new version of the web app and 706 00:40:44,800 --> 00:40:47,640 you don't have that physical versioning. 707 00:40:47,920 --> 00:40:51,760 So that's built in. And so the versions are then 708 00:40:51,760 --> 00:40:55,400 supported by tags. So if you're developing 709 00:40:55,400 --> 00:41:00,600 something and it's just part of APR or it's on a branch, then 710 00:41:00,600 --> 00:41:03,560 you would tag it with that. And so then you can test new 711 00:41:03,560 --> 00:41:06,440 features against what's in production because the 712 00:41:06,440 --> 00:41:11,600 provider's tagged a specific version in the broker with 713 00:41:11,840 --> 00:41:13,880 production. So then you can point your 714 00:41:13,880 --> 00:41:16,800 feature branch to the production version of the API. 715 00:41:17,160 --> 00:41:20,280 And then the API might move forwards, but they might not 716 00:41:20,280 --> 00:41:22,800 release that to production until later on. 717 00:41:23,080 --> 00:41:27,520 So now you've got that matrix and the Pepper relies a matrix. 718 00:41:27,520 --> 00:41:31,960 So you can see OK, which versions of the consumer are 719 00:41:31,960 --> 00:41:34,200 verified with which versions of the provider. 720 00:41:34,640 --> 00:41:37,120 And it gives you that nice visual. 721 00:41:37,360 --> 00:41:42,440 And so you can develop in isolation without having to rely 722 00:41:42,440 --> 00:41:46,080 on that communication of OK, I've deployed this version. 723 00:41:46,080 --> 00:41:49,640 I'm going to deploy it there for an hour so you can test it and 724 00:41:49,640 --> 00:41:53,200 then we'll switch back to the production version so that we 725 00:41:53,200 --> 00:41:54,920 don't break any of the other consumers. 726 00:41:55,200 --> 00:42:00,160 So yeah, it's that versioning which becomes very complicated 727 00:42:00,400 --> 00:42:03,080 very quickly in a micro services. 728 00:42:03,080 --> 00:42:06,520 Environment, right? So yes, this is probably 729 00:42:06,520 --> 00:42:08,880 something that pack also helps you out-of-the-box, right? 730 00:42:08,920 --> 00:42:11,320 So if you have to support multiple versions, you don't 731 00:42:11,320 --> 00:42:13,640 have to maintain your own matrix, right, All these 732 00:42:13,640 --> 00:42:15,360 permutations of different versions. 733 00:42:15,800 --> 00:42:17,640 So I'm actually still intrigued about this. 734 00:42:17,640 --> 00:42:21,160 Consumer driven, right? Traditionally in the past, the 735 00:42:21,160 --> 00:42:24,120 provider is the king, right? They would just tell everyone, 736 00:42:24,120 --> 00:42:27,520 OK, this is my API, you use it or whatever, right? 737 00:42:28,080 --> 00:42:31,560 So obviously normally there's no room for kind of like the 738 00:42:31,560 --> 00:42:36,160 consumer to drive the API. So how come this time is kind of 739 00:42:36,160 --> 00:42:38,680 like flip, right? I mean, consumer driven contract 740 00:42:38,680 --> 00:42:40,240 testing, the consumer is the king, right? 741 00:42:40,240 --> 00:42:43,800 They can actually shape the contract and the provider has to 742 00:42:43,800 --> 00:42:47,800 follow them. So tell us why this interesting? 743 00:42:48,000 --> 00:42:51,400 I don't know evolution in terms of, you know, the power between 744 00:42:51,400 --> 00:42:52,880 the API provider and the consumer. 745 00:42:52,880 --> 00:42:56,240 So why this makes more sense instead of the traditional one? 746 00:42:57,040 --> 00:43:01,880 Yes, a really great point. So the IT kind of comes from 747 00:43:02,000 --> 00:43:05,640 Postel's law, Postel, however you pronounce it. 748 00:43:06,120 --> 00:43:11,120 So it's be conservative in what you do, be liberal in what you 749 00:43:11,120 --> 00:43:13,840 accept from others. So it's kind of come from that 750 00:43:13,840 --> 00:43:17,880 concept. And the idea is putting those 751 00:43:17,880 --> 00:43:21,000 users first. So when we're developing our 752 00:43:21,000 --> 00:43:23,920 APIs, there's often in requirements. 753 00:43:23,920 --> 00:43:28,120 It's like, OK, this consumer needs this information in this 754 00:43:28,120 --> 00:43:30,760 format. And so it's being driven from 755 00:43:30,760 --> 00:43:32,720 there. It's like, OK, the consumer 756 00:43:32,720 --> 00:43:36,440 needs this information. So how do we put that into our 757 00:43:36,440 --> 00:43:38,720 API? And then it's like, OK, this 758 00:43:38,720 --> 00:43:41,000 consumer needs it in this format. 759 00:43:41,320 --> 00:43:45,920 OK, well, maybe that doesn't sit inside this API because this is 760 00:43:45,920 --> 00:43:49,920 for this purpose. And so it's trying to narrow 761 00:43:49,920 --> 00:43:53,960 down those requirements and trying to make it purely based 762 00:43:53,960 --> 00:43:57,560 on what's going to be consumed. Another example of that, right, 763 00:43:57,560 --> 00:44:01,800 is how often do you have information within the API which 764 00:44:01,800 --> 00:44:05,960 is never used? Obviously you can see within, 765 00:44:06,000 --> 00:44:10,280 you can ask the other teams like are you using these data points 766 00:44:10,280 --> 00:44:14,040 or in the logs you could potentially see, OK, we filter 767 00:44:14,040 --> 00:44:17,400 the data by this, but no one ever filters the data by that. 768 00:44:17,800 --> 00:44:23,400 And so it's like also enabling you through the data to say, OK, 769 00:44:23,400 --> 00:44:26,160 these are the only areas which are being used. 770 00:44:26,400 --> 00:44:30,800 So maybe we can reduce down our API or maybe we need to split it 771 00:44:30,800 --> 00:44:34,480 in two because we're getting lots of traffic and they're 772 00:44:34,760 --> 00:44:38,000 requesting this filter, which is really expensive. 773 00:44:38,000 --> 00:44:40,680 So let's just put that into another API. 774 00:44:40,680 --> 00:44:45,640 So it's trying to have a data-driven approach to breaking 775 00:44:45,640 --> 00:44:49,400 down those requirements to what do we actually need to provide. 776 00:44:49,800 --> 00:44:52,240 So it makes, yeah, it makes a lot of sense. 777 00:44:52,240 --> 00:44:56,040 And then, as you said, about like the power of the provider, 778 00:44:56,040 --> 00:45:00,800 right, is usually the provider will create their tests, which 779 00:45:00,800 --> 00:45:05,120 will say the API returns this. And then when they make a 780 00:45:05,120 --> 00:45:08,160 change, they will update their own tests. 781 00:45:08,760 --> 00:45:11,960 How often do we say like, don't test your own code? 782 00:45:12,440 --> 00:45:15,040 And it's like, well, why don't we do the same with APIs? 783 00:45:15,040 --> 00:45:18,160 Because the consumers should be the one testing it because 784 00:45:18,160 --> 00:45:20,440 they're the ones that rely on it, right? 785 00:45:20,880 --> 00:45:24,080 So yeah, there's lots of examples that I've had in my 786 00:45:24,080 --> 00:45:28,120 career, right, where you just change your own tests because we 787 00:45:28,120 --> 00:45:32,600 did make a change, so we know it's broken, so we change it and 788 00:45:32,600 --> 00:45:34,400 then we've broken the integration. 789 00:45:34,840 --> 00:45:37,480 So yeah, that's where kind of the consumer driven approach 790 00:45:37,480 --> 00:45:39,320 comes from. Right. 791 00:45:39,600 --> 00:45:42,280 I would also imagine maybe sometimes I don't know whether 792 00:45:42,280 --> 00:45:44,440 this is true, right? You can correct me if I'm wrong, 793 00:45:44,440 --> 00:45:46,040 right? So even though the consumer 794 00:45:46,040 --> 00:45:48,680 generates the contract, the provider can still negotiate, 795 00:45:48,680 --> 00:45:50,760 right? So it's not like every different 796 00:45:50,920 --> 00:45:53,440 version of contract generated by consumers, they will just 797 00:45:53,440 --> 00:45:55,520 satisfy, right? So again, communication is the 798 00:45:55,520 --> 00:45:57,480 key. Is that correct by the way? 799 00:45:58,280 --> 00:45:59,920 Yeah, that's a really, really good point. 800 00:45:59,920 --> 00:46:04,720 So obviously if there's a failure and providers fails 801 00:46:04,720 --> 00:46:10,080 because the consumer is asking something ridiculous or even 802 00:46:10,080 --> 00:46:13,640 asking something small, right, like date format back, we return 803 00:46:13,640 --> 00:46:15,440 it in this and you're expecting it in this. 804 00:46:15,560 --> 00:46:18,400 Well, we can't return it in multiple different formats. 805 00:46:18,400 --> 00:46:23,040 That's impossible. Or if there's a specific null 806 00:46:23,040 --> 00:46:27,280 value or like there's a empty or whatever, there has to be a 807 00:46:27,280 --> 00:46:30,920 consistent way to do that. So the provider has to say at 808 00:46:30,920 --> 00:46:33,560 certain points we cannot do that. 809 00:46:33,840 --> 00:46:38,560 And so the provider still has lots of power, but it's just 810 00:46:38,920 --> 00:46:42,200 driven by that communication of, OK, we would like it like this, 811 00:46:42,760 --> 00:46:46,240 how can we come to a solution? Right. 812 00:46:46,480 --> 00:46:49,560 Thanks for clarifying that. I think it's very interesting 813 00:46:49,560 --> 00:46:52,800 take for those people who want to try this contract testing, 814 00:46:52,800 --> 00:46:55,200 right. I think in this era, not just 815 00:46:55,200 --> 00:46:59,240 REST AP is or HTTPAPIS that people normally use for 816 00:46:59,240 --> 00:47:01,640 integrations. So there's this asynchronous 817 00:47:01,640 --> 00:47:04,600 communication as well, or message driven or event driven 818 00:47:04,600 --> 00:47:07,680 architecture, right? Does contract testing help for 819 00:47:07,680 --> 00:47:10,840 that kind of scenario? And if so, how does this 820 00:47:10,840 --> 00:47:14,560 contract testing now play a part in that kind of architecture? 821 00:47:15,320 --> 00:47:18,640 Yeah, absolutely. So event driven is another one 822 00:47:18,640 --> 00:47:22,440 of the ones that recommends for people who are getting started 823 00:47:22,440 --> 00:47:28,240 with contract testing because an event is like a small section of 824 00:47:28,240 --> 00:47:31,560 data and it's like a small piece of communication. 825 00:47:31,920 --> 00:47:35,160 And so it's a really nice way to get started because the 826 00:47:35,160 --> 00:47:38,160 parameters are a bit less and often you're just passing it 827 00:47:38,160 --> 00:47:41,720 around. Sometimes the service isn't even 828 00:47:41,720 --> 00:47:44,520 storing anything or passing it into another system. 829 00:47:44,800 --> 00:47:48,600 So a Venturefin is definitely supported within contract 830 00:47:48,600 --> 00:47:51,160 testing. The message part is all we care 831 00:47:51,160 --> 00:47:57,320 about, right? So it's not tied to any tool or 832 00:47:57,320 --> 00:48:02,160 any event driven architecture kind of facilitator. 833 00:48:02,440 --> 00:48:06,720 So like Kafka or AWS SMS, anything like that. 834 00:48:07,080 --> 00:48:09,640 It's not tied to anything, it's just a message, right. 835 00:48:09,640 --> 00:48:16,000 So if your events are heavily tied to those and you can't 836 00:48:16,240 --> 00:48:20,760 separate the contract message from that, then contract testing 837 00:48:20,760 --> 00:48:23,520 doesn't work. But if you've got a good way of 838 00:48:23,520 --> 00:48:27,400 constructing your event message, then you could definitely verify 839 00:48:27,840 --> 00:48:32,880 that that contract is supported. So I think in EDA you will also 840 00:48:32,880 --> 00:48:35,200 have this concept of producer and consumer, right. 841 00:48:35,520 --> 00:48:39,600 So is it still the case that the consumer is the one driving the 842 00:48:39,600 --> 00:48:41,320 event? Because I would imagine is the 843 00:48:41,320 --> 00:48:44,080 producer that kind of like push the message, right? 844 00:48:44,080 --> 00:48:47,000 So is this still the case for the event driven? 845 00:48:47,920 --> 00:48:51,600 Yeah, I always get this so confused, so confusing. 846 00:48:52,200 --> 00:48:54,920 But yeah, it's flipped on the event of it, right? 847 00:48:54,960 --> 00:49:00,520 So the producer is the consumer and the consumer is the provide, 848 00:49:00,840 --> 00:49:04,000 but check the book because it's definitely right. 849 00:49:05,840 --> 00:49:08,800 But no, yeah, it's flipped. Obviously the terminology is 850 00:49:08,800 --> 00:49:13,800 very confusing, but the producer generates the contract and then 851 00:49:13,800 --> 00:49:17,160 the consumer is very fine. Interesting. 852 00:49:17,160 --> 00:49:19,960 So, OK, so maybe we'll use the different term publisher and 853 00:49:19,960 --> 00:49:22,040 subscriber so that you don't get confused. 854 00:49:22,360 --> 00:49:23,320 Exactly. Right. 855 00:49:23,960 --> 00:49:27,560 So thank you so much for this overview about contract testing. 856 00:49:27,600 --> 00:49:30,360 I think for people who deal with a lot of integrations, this 857 00:49:30,360 --> 00:49:33,440 definitely is one of the tools that you have to utilize in 858 00:49:33,440 --> 00:49:36,160 your, I don't know, CICD pipeline or development process 859 00:49:36,440 --> 00:49:39,160 so that you can get the confidence to deploy your 860 00:49:39,160 --> 00:49:42,280 integration changes right as we reach the end of our 861 00:49:42,280 --> 00:49:44,400 conversation. I have one last question for 862 00:49:44,400 --> 00:49:47,080 you, Lewis, which I called the Tree technical leadership 863 00:49:47,080 --> 00:49:49,360 wisdom. So if you can think of it just 864 00:49:49,360 --> 00:49:51,840 like an advice that you want to give to ask the listeners here, 865 00:49:52,040 --> 00:49:54,400 maybe if you can share what is the version of your Tree 866 00:49:54,400 --> 00:49:56,640 technical leadership wisdom. Yeah. 867 00:49:56,640 --> 00:49:59,160 Thank you. Yeah, hopefully what I've spoken 868 00:49:59,160 --> 00:50:02,240 about makes sense. But yeah, the theme throughout 869 00:50:02,440 --> 00:50:05,360 the conversation has been communication. 870 00:50:05,680 --> 00:50:10,000 So that's definitely my number one is be very open with that 871 00:50:10,000 --> 00:50:13,320 communication and keep those, the avenues of communication 872 00:50:13,320 --> 00:50:17,000 open. And I do think that the large 873 00:50:17,000 --> 00:50:19,680 majority of software delivery is about communication. 874 00:50:19,680 --> 00:50:22,080 So that would definitely be my number one. 875 00:50:22,520 --> 00:50:26,800 My number two is breaking down those barriers of quality. 876 00:50:26,800 --> 00:50:30,600 So dev and test is one thing, right? 877 00:50:30,600 --> 00:50:33,280 Like at the end of the day, we're trying to deliver a 878 00:50:33,280 --> 00:50:37,600 quality product at the end. So breaking down those barriers 879 00:50:37,680 --> 00:50:41,440 and making sure that everyone has that quality bindset built 880 00:50:41,440 --> 00:50:44,200 in from the start. So that would be my number two. 881 00:50:44,720 --> 00:50:49,640 And then, yeah, my third one would just be to keep a kind of 882 00:50:49,640 --> 00:50:53,720 general holistic view of software development. 883 00:50:54,120 --> 00:50:56,480 So I've always been a generalist. 884 00:50:56,640 --> 00:51:00,200 I have my fingers in the lot of pies, but I think that's really 885 00:51:00,200 --> 00:51:03,240 helped me, especially in leadership, is having that 886 00:51:03,240 --> 00:51:06,680 holistic view and being able to contribute to lots of different 887 00:51:06,680 --> 00:51:10,280 conversations. So yeah, that would be. 888 00:51:11,480 --> 00:51:13,800 Thanks for sharing that. I like the second one, right. 889 00:51:13,800 --> 00:51:17,560 So remove breakdown all the barriers for quality result or 890 00:51:17,560 --> 00:51:20,160 quality mindset, right? So I think this is key still in 891 00:51:20,160 --> 00:51:21,520 any software development team, right? 892 00:51:21,520 --> 00:51:24,760 You want to produce product of high quality, right? 893 00:51:24,800 --> 00:51:27,520 And contract testing definitely is one tools that you can 894 00:51:27,520 --> 00:51:30,640 explore for that. So for people who would love to 895 00:51:30,640 --> 00:51:32,840 learn more about contract testing or maybe they are 896 00:51:32,840 --> 00:51:36,000 waiting for your book or maybe a place where they can find you 897 00:51:36,000 --> 00:51:38,440 online, is there a place for them to find you? 898 00:51:39,280 --> 00:51:41,800 Yeah, absolutely. Obviously, you can go to Manning 899 00:51:41,880 --> 00:51:43,840 and search for contract testing in action. 900 00:51:44,160 --> 00:51:46,120 There's live discussion on there. 901 00:51:46,480 --> 00:51:51,680 And then you can find me on LinkedIn, Lewis Prescott and 902 00:51:52,080 --> 00:51:55,280 also on my website, pacman.co.uk. 903 00:51:55,760 --> 00:51:59,600 And we should also mention that the co-author of my book, Marie 904 00:51:59,600 --> 00:52:01,640 Cruz is having a baby at the moment. 905 00:52:01,640 --> 00:52:04,200 So she can be here today, unfortunately. 906 00:52:04,200 --> 00:52:08,280 But obviously, yeah, you can connect with her as well on 907 00:52:08,280 --> 00:52:12,160 LinkedIn and we're more than happy to answer any questions 908 00:52:12,160 --> 00:52:13,840 that you have on contract testing. 909 00:52:15,040 --> 00:52:17,080 Right. So let me put that all in the 910 00:52:17,080 --> 00:52:18,880 show notes. So thank you again for your time 911 00:52:18,880 --> 00:52:20,720 today, Louis. So I hope people learn about 912 00:52:20,720 --> 00:52:23,320 contract testing and they get excited to actually give it a 913 00:52:23,320 --> 00:52:24,880 try. So thanks again for your time.