 We've got a lot of cool new features in Qarkis 3. One of the things that I've been working on is improved pack support. Packed is a contract testing framework, and contract testing allows you to test microservices systems in a way that avoids a lot of the expense and pain of end-to-end testing while still giving you the confidence of end-to-end testing. So it's pretty cool. Let me show you what's new. I've got a little application here. It's just a simple retail flow. So I can order a sweater, and then it goes through a flow. So it goes from a BFF to a knitter who knits the sweater, but the knitter needs wool from a farmer, and you can see that there's messages flowing along at each stage. How would I test this? Well, the knitter provides a sweater resource. When a sweater order comes in, the knitter knits the sweater and passes it back, but they need wool from the farmer. How I might normally test this is something like this. So I've got a test for my endpoint, and I inject in a mock. But the problem is I have no idea whether that mock is actually correct. So this is where PACT helps. So the PACT test is actually pretty similar. I'm still trying to test my sweater endpoint, and so this bit of code is actually identical, but I define the mock in a different way. I define the mock using the PACT DSL, and so I say what I expect the farmer to do. And why this is powerful is that PACT turns that DSL expression of desire into a contract, and I can share that contract with the provider, either using a PACT broker or checking it into their source control, or here I've actually just copied it back and forth on my own local file system, and that means that I get a lot more confident that the two sides have the same understanding, the same validated understanding of what's supposed to happen. And so this is just plain PACT, and you've been able to run PACT in Quarkis for a while, but not with continuous testing. And of course you want to run continuous testing because continuous testing is cool. But so now if I go, I've got it with, we have a new Quarkis PACT extension that supports continuous testing and more stuff is coming. So now if I go here and I change that, then boom, my continuous testing points out, it doesn't compile. And if I fix it, then all is good. So I'm able to do that continuous testing. On the provider side, it's similar. So I have a wool resource when an order comes in, the farmer goes and shears the sheep and sends back wool. I have a normal unit test and I have a contract test. Here you can see the contract test is actually a lot smaller than the normal unit test. It's just a template, a J unit template, and all of the information about what we expect, the wool resource to do is in that contract. So why is this useful? How does this help? Well, let's look at what happens if I make an improvement. Here I've used the British spelling of color. That might annoy some of my colleagues. So let's do a refactor and let's change it to the American spelling. So we do the refactor. And now let's look at my unit tests. Make sure I didn't mess anything up. So I run my tests and yeah, it's all good because the IDE has helped me out and where things changed name. It just sorted it out. So my unit tests are good. Everything should be good, right? Well, let's see. So let's go back to the actual application and order another white sweater. So let's order that. It kind of looks like it's okay. So I pass back the color here. But then when I get to the knitter, the color is null. And you can see that reflected in the UI. It says my new sweater is a totally undescribable sweater, sad lambda. What's going on? Why didn't my unit tests catch this? Well, they didn't test it, catch it because the IDE helped me out. But of course the IDE couldn't help the other side out. And this is where the contract tests help. So if I look at my terminal, I've got the contract tests running with continuous testing. I do have to re-trigger it. But once I've re-triggered it, it tells me exactly what the problem is which is that I changed the spelling of color. So this kind of problem wouldn't be caught by unit tests, probably. It would be caught by open API. But PACT can catch a lot of things that open API validation wouldn't. So how it works at the moment with my demo application is that if I ask for white wool, I get white, the farmer finds a white sheep. If I ask for brown wool, the farmer finds a brown sheep. If I ask for black wool, the farmer finds a black sheep. What if I ask for pink wool? Does the farmer find a pink sheep? Does the farmer now have responsibility for dyeing the wool? There's not really a right answer. But what's important is to ask that question and have that conversation. And this is where something like an open API test couldn't really do that deeper validation about the behavior for pink. But PACT really can. It's quite useful for this kind of testing. And what it means overall is that because you have that confidence and you've got that confidence pretty cheaply, then hopefully you get to a place where you can deploy with more confidence, which means you can deploy more often. And that's a good thing. That's the promise of microservices.