WireMock with Tom Akehurst

[00:00:08] In a land of testers, far and wide they journeyed. Seeking answers, seeking skills, seeking a better way. Through the hills they wandered, through treacherous terrain. But then they heard a tale, a podcast they had to obey. Oh, the Test Guild Automation Testing podcast. Guiding testers with automation awesomeness. From ancient realms to modern days, they lead the way. Oh, the Test Guild Automation Testing podcast. With lutes and lyres, the bards began their song. A tune of knowledge, a melody of code. Through the air it spread, like wildfire through the land. Guiding testers, showing them the secrets to behold Oh, the Test Guild Automation Testing podcast. Guiding testers with automation awesomeness. From ancient realms to modern days, they lead the way. Oh, the Test Guild Automation Testing podcast. Oh, the Test Guild Automation Testing podcast. With lutes and lyres, the bards began their song. A tune of knowledge, a melody of code. Through the air it spread, like wildfire through the land. Guiding testers, showing them the secrets to behold.

[00:00:34] Hey, want to know more about open source API mocking and how it can help you with the testing? Well, you're in luck because today, we'll be speaking with Tom, the creator of the open source API mocking tool WireMock, which he's now been working on for well over a decade. He also is the CTO and co-founder of WireMok Cloud, where he's helping complex engineering organizations unlock productivity gains by adopting API simulation techniques. At scale, I think it's the technique that a lot of testers miss out on. Tom has over 20 years of experience. He really knows his stuff. You don't want to miss it. Check it out.

[00:01:06] Every front end developer I know seems to constantly face two major obstacles that derail productivity and delay releases. First one is dependency on back end developers to complete APIs before front end work can progress and unreliable back end services during development and testing. Traditionally, HTTP interception and mocking tools like child's proxy require complex system setups. SSL certifications, and often break with corporate VPNs. Build your own solution. Let's face it, that's development time you can't afford to lose. And that's where Requestly by BrowserStack steps in. Requestly is an open source Chromium based browser extension that fits seamlessly into your existing workflows. There's no learning curve. It offers tools, HTTP interception, debugging, and mocking to solve for comprehensive use cases including cloud based mocking, JS redirection, local support, and more. Plus, it provides comprehensive request response inspection with debugging API integrations and enabling seamless team collaboration through workspaces. And what's even better is this lightweight extension requires zero setup, eliminating the need to manage system level proxy settings or having to install SSL certifications. It's a privacy friendly and fully compatible with corporate VPNs and also Requestly is an enterprise ready tool offering features like SSO, SLEs, SOC 2 compliance, reporting, and analytics and rule based access control for efficient enterprise management. And as you probably already know, it's also well loved by the developer community with over 200,000 users and a rating of four point three out of five rating on the Chrome Web Store. And even better, the base plan is completely free. No credit card required. Just install the browser extension and get started today using the special link down below. Now on with the show.

[00:03:09] Joe Colantonio Hey Tom, welcome to The Guild.

[00:03:12] Tom Akehurst Hey, thanks for having me on.

[00:03:14] Joe Colantonio Great to have you. As I mentioned in the pre-show, I've heard of WireMock for a while. Just curious, like, what have you been doing for 20 years? You've been working on this for over a decade. What originally inspired you, I guess, to create WireMock? And where have you gone now? I think you've done other things now at WireMock Cloud. And what is that?

[00:03:30] Tom Akehurst So, yeah, I've been working on WireMock open source for about 14 years. And the thing that originally sparked here, I was working as a consultant for a long time and I was working on projects that often involve kind of complex integration problems, service-based, microservice-based. And I was on a particularly large, it was sort of pre-micro services, but still kind of a big sort of Rest API service oriented architecture. And I was building an app that was kind of talking to lots of different APIs made by lots of different teams and other companies within the organization and kind of nothing worked. It was impossible to test anything. Things were getting stuck in the kind of ready to test column because of lack of test data, because of lack of stable environments, because things have been built that didn't actually conform to the spec that had been written, all those kinds of problems, which I'm sure are very familiar to anybody who's built software in kind of distributed enterprise environments like that. I ended up building the tool just as a kind of scratching my own itch thing. I'd kind of half sold it sort of within private code bases a couple of times before, and I kind of thought I want something that I can take to projects and reuse rather than reinventing this wheel over and over again. Cause I started out that way.

[00:04:47] Joe Colantonio Love it. What's it involved to now, because I think I've seen some newer functionality coming out that I think you're expanding on and maybe the base of what you the foundation that you created.

[00:04:57] Tom Akehurst Yeah. So I mean, it's evolved a lot over the years. I mean the core fundamentals of WireMock is that it's an API mocking tool. By that it is mocking protocols kind of over a network. And that's kind of, yeah, distinct from the kind of mocking that you might do with a tool like Mockito where you're sort of, you're mocking inside the code itself. You are mimicking the behavior of a networked API. So then you can, if you're testing an app that talks over a network to something, then as far as that app is concerned, it's talking to the real thing, it sort of can't tell the difference. And crucially, that means you're sort of testing your real production code in terms of the code that integrates that your app with your dependent API's. And the fundamental building block is this kind of stubbing is really in a request response pair. You say if I receive a request that matches these criteria, then send this canned response or use this recipe to kind of build a response. That's the sort of fundamental of it. And it's simple enough in concept, but then kind of over the years, there's been lots of elaboration on that. There's being the addition of dynamic templated responses. Sometimes just sending a canned response is not enough. If you've got things like you need to recalculate dates, or if you want to pass tokens around between request and response, that kind of thing, you can do that dynamically. There's lots and lots of flexibility around request matching. So sometimes, so again, dates, that's sort of one of my favorite topics. If you make a request which has got a date in it and you kind of care what the relationship of that date is to now, rather than what it is absolutely. So you want to say, is this date in the past or in the future and make your matching decision on that. There's all that kind of stuff. And then there's been extensions built for other protocols. We've got GRPC support as an extension, GraphQL. There's an extension for adding JSON web token support. So if you want to kind of build like OAuth, OAuth type workflows, and generate signed tokens, and you can do that. There's kind of a whole host of stuff. I mean, I could keep going and going, I should probably pause at this point.

[00:06:57] Joe Colantonio No, no, I love it. I guess, it has been around for a while. You started because you were working maybe in a complex engineering organization, as you mentioned. Is this still people or developers that have to decide, like, when do I use mocking an API versus the full integration test?

[00:07:12] Tom Akehurst Yeah, absolutely. I mean, I have a very sort of biased view of this because I spend all day every day practically kind of talking to people who have either made this decision or they're thinking about making this decision. I'm in a way it surprises me how many people you see still not making the decision to use mocks and who, they take the view that they're not trustworthy, that if you use mocks, then you're running the risk and kind of producing false positives in your testing and that's just going to push maybe even all the way into production, the point where you discover integration bugs and so on like that. There's kind of a lot of latent skepticism around it, I guess. I think also when, when people do choose to use it, there's a sort of a wide spectrum of ways in which you can use it. And there's the one that most people do where you're kind of embedding mostly sort of code-driven mocks right next to your code and you're using them sort of similarly to how you would use object mocks. Which is kind of, I mean, WireMock Open Source is very well designed for that. I mean it has a rich Java DSL, it allows you to sort of work that way very expressively, but I think that there's then this whole spectrum of additional ways you can deploy it and get value from it where you can kind of like a sort of outer shell of mocks around a whole set of, for instance, microservices that you're testing together. Sort of at the other end of the scale, like one deployment pattern we see quite a lot is where companies will mock all of their third party dependencies, so everything is being provided by their partners, their SaaS vendors, all that kind of stuff. But then they'll integration test the bits in the middle that depend on that sort of out of shell of API's. And there isn't one size fits all, there are some companies that will deploy and test individual microservices with a sort of complete each one of them with an individual kind of isolation layer around the outside. Some will kind of take small combinations of sort of tightly integrated services and then mock everything else. There's definitely a requires a bit of thinking and understanding the trade-offs, I think, in order to use it well in that regard.

[00:09:19] Joe Colantonio All right, so what are some mistakes people make when deciding then? Maybe they go down the wrong path because they made the wrong assumption?

[00:09:26] Tom Akehurst Yeah, that's a good question. I think you definitely see people who are sort of overly keen to sort of push it into every, to isolate everything over eagerly, maybe. And I think create a lot more work for themselves than is necessary. I mean, I think there is a healthy balance to be struck. Sometimes kind of integration testing. If you've got two services that collaborate particularly closely and particularly if the team's working on them are working closely together. Then you don't always need a sort of mock boundary between them. You can mock outside of them and integrate them. And so there's definitely that. I think there's also sort of how people choose to design the actual mocks themselves and how they maintain them is, I probably see people making more mistakes or sort of suboptimal choices, I guess, in that regard, where people will, yeah, for instance, try and use record and playback for absolutely everything and not have a strategy for generating or enhancing stubs, it's a bit more sophisticated. They create this huge maintenance burden kind of recording hundreds or thousands of requests from all of their APIs and then having this problem of sort of constant obsolescence in them, where they're having to sort of rerun and recreate and recheck these things all the time. That can definitely be burdensome.

[00:10:40] Joe Colantonio Makes sense. I always have with these class of tools, they always have a lot of awesome functionality. And maybe I'm wrong. Maybe sometimes I think they get looked over because a developer wants to develop code, a tester wants to test, testers use certain types of code, developers use others. And I think this type of it's almost bridges the gap between the two. Maybe I'm long. Do you see this then as a developer productivity tool or does it offer test coverage benefits and who should be using it?

[00:11:09] Tom Akehurst I mean, I think it's a bit of both. I think, it's great for developer productivity, particularly when you've got the kind of API doesn't exist yet problem where you've got two teams, one's producing an API and then the other one's consuming it, or maybe you've gotten more than one who are consuming it and the organization as a whole wants to build a new product feature and we need a new API for that before the consuming teams, mobile teams, web teams, whatever can build it and being able to say we will collaborate, build a mock and then everybody can go away and use that as their reference. The consuming teams can build on top of this immediately. And the producing teams have got something arguably better than just the specification document that they can use to go and build an implementation. It's definitely productivity enhancing there because it parallelizes work that would otherwise have to happen kind of in series, but there are many ways in which it also helps reduce the cost and effort of testing and also expands test coverage. I mean, one of the ways I like to think of it is it kind of flattens out the cost of setting up the preconditions for different types of test case whether you want a test case with a simple sort of single record being served from an API, or whether you one which has got sort of hundreds or thousands of records being returned in a list over several pages in a sort of fully integrated environment for the latter of those, you probably find yourself kind of inserting lots of records into a database or writing a script that calls an API over and over again in order to seed with test data. And in practical terms, that's quite a lot of work. And sometimes when pressures are on, those are the types of test cases that get dropped on the floor first because they're high effort. Likewise, with kind of injecting faults and something like that, it's just as easy to mock a fault as it's sort of a happy path case, whereas integrated tests you-most test environments you can't force them to make errors on demand, you have to do something fairly unpleasant to them in order to get them to reliably produce errors and then they're doing it for everybody, which is not so great. Being able to kind of say, for instance, if like a request is made and it's got this magic email address in that I want to trigger a fault, then I can do it just in those circumstances and then I can very easily establish how my application under test behaves when I see that fault, but I don't have to deal with this kind of disruptive work in order to discover that.

[00:13:33] Joe Colantonio I think that's a great use case. Once again, I think a lot of people miss out on. They probably just focus on happy path, but this sounds perfect for negative testing or like chaos engineering almost to see how does they handle gracefully when something's done or the service isn't available.

[00:13:47] Tom Akehurst Yeah, absolutely. I mean, there's a whole WireMock in particular has got a whole raft of kind of fault features in it. So you can return sort of HTTP level errors from it that are within the well formed HTTP kind of faults, but then you can drop down a layer and you can do kind of network faults as well. So you can say, if we receive this request, then just drop the connection or send a reset packet. Those kind of things that happen when, again, like if you're in a microservices environment, and your system's under pressure and web servers are starting to kind of brown out they're not completely failing but they're sources dropping connections for some requests or failing in ways that are kind of happening at the infrastructure layer then you can test those things very easily and you can either do it deterministically or actually i'm plugging slightly here but in WireMock Cloud there is also a chaos mode that is kind of a randomizer for that, you can say that you want a certain percentage of requests to fail. And you can say what specific types of failure are going to be in the mix there. And that just means you can kind of, yeah, if you're running a soak test or something, you can just kind of switch it on. You can crank up the amount of errors that are occurring and get a sort of quick view of how does my system handle this? Does it stay stable? Does it kind of degrade gracefully for my end users, or does it just kind of die in a smoking heap on the floor and sort of have to be restarted from the ground up to make it work again.

[00:15:11] Joe Colantonio Absolutely. How realistic should a Mock be at? Is this just throwaway code? Or, I mean, should we make them hyper realistic? Or is there a happy medium? Or I guess it depends, I guess, I don't know.

[00:15:19] Tom Akehurst Yeah, it's definitely a depends one, but I suppose one that there was a few heuristics that I'd use to determine that I think a key one is kind of this thing about the context in which you're deploying your mocks. I think when you're building the kind of mocks that are close to your code, that are where you're writing sort of narrow kind of unit like tests that are really examining one single state transitional one very fine grained operation in your code, you can get away with very simple. Stateless stubs, usually in that kind of case with canned responses. Generally that's good enough because you're, like I say, you're kind of examining this very small specific controls transition often where you have kind of full control over all of the input data and everything else. If you go to the other end of the scale where you're often, sort of if you're the situation I described earlier, where you've got maybe a bunch of collaborating services and you're testing sort of at the feature level. Maybe even you've got this stuff deployed, someone's doing an exploratory test and an interaction in a, maybe a user facing application in practice will sort of ping off this whole workflow, this set of interactions between different components. And in that case, you tend to need to raise the realism quite a bit in order to support those cases. The most common thing we see, and this is something we've been building quite a lot of stuff around recently is statefulness. Being able to capture data from one request one interaction and then reuse it in a subsequent one. Then you avoid the situation where you get these weird, apparently glitchy behaviors where sort of all of the API calls have been made correctly. But like the UI hasn't updated with the things that I typed in because by default mocks are stateless. And so they're just going to keep returning whatever the state was at the beginning. I think there's, if you're trying to model these sort of coarser grained interactions and the things you're testing is closer to what the end user is experiencing, then realism is more important. Whereas if you'll down near the code, then it's less important.

[00:17:24] Joe Colantonio Is a mock just for pre-production? Would you ever deploy a mock to production? I don't know if that makes sense. Like would you have a test in production? And because you have a mock, you can test in production?

[00:17:35] Tom Akehurst Yes, it does happen. Few years ago, I was doing performance engineering work for a big retailer over here in the UK. And they had a typical kind of they made all their money on black Friday and there was loads and loads of preparation, loads of performance testing and performance engineering where it would happen in the lead up to it. And they wanted to do as much testing and production as possible. They had, essentially that their integration with their payment gateway I have this bit of logic in it that said if the person doing the pay had a certain email that magic email domain or something like that would route the payment request to a WireMock instead of the real payment gateway. So then the load generator would only generate customer emails with this magic domain in there, which meant that all of the payment requests would go off to a mock instead. So that way they weren't sort of attempting to hammer whoever their payment provider was payment gateway and getting totally because the thing with payment gateways, particularly the older ones is their sandboxes are not scaled up for performance testing. And even if you somehow get to do it, the performance characteristics is completely different to how they would actually be for instance, on Black Friday anyway, so it's kind of a pointless exercise. Whereas if you drop a mock in there, then you can get something more realistic, but you can still exercise the rest of the production system. I've seen examples like that a few times. I seen a few slightly more esoteric ones as well, I guess. There was a company we spoke to a while ago, they were doing this hybrid thing where they were using it for diagnostics. They were capturing a mock of real interactions out here. If something went wrong in their production system, it would snapshot a bunch of API interactions, turn it into mocks, and then you could take it back down into your development environment, but with this. Like I said, this sort of snapshot of the state of the production environment that you could debug in, and I thought that was a really cool idea.

[00:19:28] Joe Colantonio Yeah, that's really I can see that being really helpful, especially before open telemetry and all that.

[00:19:33] Tom Akehurst Yeah, well, I mean, it's something one of those things I've haven't had time to explore really, but would like to being able to hook into things like open telemetry because they could work really well together. If you've got a really high resolution store of this stuff, which is being captured, and you can correlate it with when there's a problem, then it kind of made for it. You just grab all this stuff out of the ether and run some translation scripts over it. And you've gotta ready made shrink wrapped environment that replicates a problem, which is kind of a lot of environments is like testers, he's gold for testers.

[00:20:07] Joe Colantonio Holy grail. Yeah, yeah. I love it.

[00:20:10] Tom Akehurst Because the effort involved is so high and getting to what do I need to do in order to replicate this bug? So much of us have spent so much time in our careers trying to figure that stuff out that if you can just kind of automate it, then it makes you so much more productive.

[00:20:24] Joe Colantonio I might try to vibe code something like that. That's an awesome use case. I know that there are some downsides or here are some developers and testers complaining about mocks and that there's, it's hard to keep it in sync with reality sometimes. And so they call it like API drift and they make a big deal out of it. How do you recommend, is this a real deal API drift? And if so, how do you recommend teams handle?

[00:20:46] Tom Akehurst It is a real problem. I mean, it's something that we, again, we talk to customers about a lot because they want to use mocking at a scale where it becomes a really acute problem. Microservice environments. It's a particularly severe problem because you've got lots of APIs in a very high sort of state of change. They're being constantly having new things shipped to them, constantly changing and the speed at which if you've created a mock, just sort of at a moment in time when you needed it, and it was kind of aligned with the real API at the time, but then that real API has gone through a whole months and months worth of changes, then the two will diverge very quickly and hopefully fairly, obviously the sort of result in confidence that you can get from your mock will go down because it diverged from reality. This is definitely a big issue. And the things that we've been building and we've been exploring in order to mitigate that. I kind of use it, you're primarily using forms of contracts testing, I guess you'd call it, not the kind of like sort of packed start of consumer driven contract testing, but kind of, it's that really sort of traffic validation using open API primarily and that kind of technique. Making sure that there was some sort of source of truth describing what the API's contract is, and then making sure that while you're using your mocks while you are running them, that you're also validating against that contract. And if the contract changes, then you can, for instance, fail your CI builds, you can return an error and then get this sort of quick feedback that your mock and your contracts are sort of out of compliance with each other.

[00:22:27] Joe Colantonio Yeah, but it's actually going to ask you that as you were talking about contract testing, if you can use it to guard against contract violations. And it sounds like you 100% can.

[00:22:36] Tom Akehurst Yeah, I mean, it's a surprisingly complex problem in some ways. And obviously there are limits to what you can describe in a contract. I mean, there are contract is one of those fascinatingly vague terms, I think when it comes to API, it is because there are all sorts of things that there is no contract language that can really sort of describe or certainly in sort of common API uses. There are things that are just outside the scope of what you can describe with open API. It's not perfect by any means, but it's certainly anything, all the obvious kind of structural things about API's that they just routinely get broken over and over again, as API's evolve. You can very effectively catch by kind of using these techniques. Maybe I'm going into too much detail. But there's a couple of different approaches you can take for this that we sort of observed and try and facilitate. And one, there's using open API, when you've kind of adopted it widely as organization. If you have it already have kind of good habits around documenting your APIs and maintaining those documents and kind of publishing them somewhere in a way that means that people can get up to date versions of the contract and they can detect when a change has happened and all that kind of thing. If you do that, then that's great. That's gold because then you can take that, that contract, ideally the producer of the API is making, and you can just keep constantly validating your mocks for it. You'll get a a really sort of high validity sort of fast feedback about whether your mocks are valid. But failing that, you can also take a kind of, you can build your own contracts of other people's APIs. The other thing we support doing cloud is you can make a recording, so funnels and traffic through to an API and we will build an open API document for you while you're doing that. If there are, you can just essentially keep re-recording the same API over and over again, and then the resulting open API is the kind of source of truth at that particular point in time, and then you can use that for validation and check to see if things have changed.

[00:24:44] Joe Colantonio It's auto generating a mock up based on the spec. It's how that works?

[00:24:48] Tom Akehurst We can go both ways. You can capture traffic, which generates a mock, which then generates the spec, or you can bring the spec in and you can generate the mock from that. And you can kind of iterate between the two as well. I mean, this is a whole other deep topic that I get a B in my butt about sometimes and try to explain briefly. I mean, both kind of representations of an API, like a mock definition and an open API, they're both sort of incomplete versions of the truth. And they both have their sort of respective strengths and weaknesses in terms of things that they say and things that don't. In a nutshell, the open API says more about the API structurally. I t's a set of constraints that tells you quite a bit about the sort of syntax of the API. But it tells you very little about behavior, whereas a mock will tell you more about behavior and less about syntax, if that makes sense. A mock you can go and hit it with different combinations of parameters and provided those things have been defined, then you can see how we can get a successful response with this combination of parameters. Maybe we get a paginated or unpaginated one depending on whether we use these query parameters. This one will give us an error. You get these behavioral variations that you can't sort of completely describe in an open API. T`he sort of, I guess the approach that we advocate for is not. And not sort of say, Oh, we're just going to throw an open API in there and generate you a mock and that's the end of it. Because generally the result you get of that is limited by the information that it's possible to represent in a spec. We take this approach of like kind of working on both at the same time, building both up at the same time because then you get the a set of information by combining the two about how the API is supposed to work. And then obviously you then have the greatest set of opportunities to know whether you're doing the right thing or not.

[00:26:39] Joe Colantonio Great advice. Love that approach. I'm also thinking as you're talking, you started this, you said 11 years ago. Obviously, AI was around, but not the way it is now with GenAI and everything and now MCP servers. Does this affect mocking at all? I mean, I know token cost has gone down. Do you see people mocking token or a ChatGPT or things like that?

[00:27:03] Tom Akehurst We built a mock in ChatGPT actually. We do want to put it in our marketplace. We have like a library of prebuilt mocks until we stuck it up there.

[00:27:12] Joe Colantonio Oh cool.

[00:27:14] Tom Akehurst A few people use it. If you want to be able to kind of get deterministic responses back, if your building an app and you want to do sort of like old fashioned checking where you don't want the response to vary every time, then it's useful in that kind of context. I think there are some more interesting kind of. I suppose intersection points between mocking and AI. I mean, in some ways, an AI is kind of an accelerant of all of the problems that mocking is good at solving. People want to be able to generate code faster, and they want to generate a code which is correct and valid and sort of tested to some meaningful standard. And they want to do that with AI. Now, all of the coding tool providers or a large number of them at least seem to be going in the direction of these remote agents, which that you as a developer kind of managing this farm of 10s, dozens, whatever, of these remote agents. And all of that creates more of the kind of problems that already existed. You need to be able to run and test code in a fast, deterministic, isolated environment, which is going to sort of give meaningful feedback. And if you're doing remote agents, then you need that environment to exist outside of your privilege infrastructure. I mean, this is an increasing problem that we're seeing is particularly like microservice developers. Again, you're often kind of working on your laptop, your laptop is on your corporate network or VPN or whatever. And that means that you've got a bunch of test environments that you can talk to. You're developing your whatever the thing is that you're working on your laptop and it can make API calls out to all of these other services. You take that and shift it into an AI providers public cloud, which has no privilege access to your network, then that's not really an option anymore. You've got to find some other way of providing the dependencies that the code that you're generating and testing needs. I think there are things like that where it's sort of creating new ways to experience the old problems. And I think the other interesting topic, and again, this is something that we're sort of actively exploring and trying to figure out what the essence of and where the edges are is this kind of this notion of feedback loops and guard rails and so on. A lot of AI based code engineering, I think at the moment is looking at how to use these techniques that provides external validation and feedback for the correctness of the thing being generated. And ideally in a way which is sort of automated and automatable so that you don't need human beings doing it. And mocking provides some really interesting opportunities here. I mean, the contract testing, the validation stuff I just talked about. That's actually really useful in a sort of code generation setting because you can say to the AI generate some code that integrates with this API, write some tests for it, run the test, and if I fail, go and look at the validation reports that the mock tool gives, go, and look at the telemetry and inside the mock tool and then figure out what went wrong. And by having that, they've got far more detail about how the code behaved how it called the API than if it's going off to some kind of black box test environment or third party sandbox or something like that. The ability to sort of use mocks as this, this sort of point in a feedback system that coding agents can use to iterate towards a correct solution. There's a lot of sort of potential power there. We're sort of starting to see how this can play out.

[00:30:50] Joe Colantonio All right, Tom, everyone seems to be having releasing an MCP server. Any information on whether or not WireMock is going to have an MCPs server? But you have one already.

[00:30:59] Tom Akehurst Yes, of course, like everyone else on the planet, we now have an MCP server for our product. I guess no one's MCP server is particularly old at the moment, where ours is relatively new, but it's already allowing some really interesting use cases to emerge. The great thing about being MCP and plugging into AI coding assistants is that you can kind of do these sort of composite changes. So you can ask the coding assistant to generate tests and then generate the corresponding mocks. Also, as I alluded to earlier, it can interrogate the telemetry from the mock and feed that information back into the coding session, all of that kind of stuff. We can already do all of that. It's great just if you want to generate more test data or more examples, it takes away so much of that grunt work of maybe I've recorded this one API call, but now I want 10 more different bits of data that kind are similar but vary in different ways. And now you can just kind of say to the coding assistant, make me 10 more of these and here's some criteria for it. It's great for doing that. And we're experimenting with some slightly more interesting use cases with it as well. The one that I'm really interested in at the moment is using it as a crawler. Kind of one thing that I've observed a lot and I've done a lot when you have an API that you want to integrate with. As a developer, I think testers end up doing this a lot as well when the thing being tested is an API. You kind of get given this partial information about it. You get some documentation or maybe somebody says, here's kind of a rough idea of how you call this thing, but you don't necessarily have complete information about. You certainly don't have a fully working mock if your information is pretty good. So then you get an HTTP client tool out and you start kind of poking it. You start making requests and some of them fail and some succeed, but eventually you kind of get an idea of the shape of the API and how to call it correctly and how it's going to respond to certain things and this is a perfect use case for AI tools because they're good at that kind of thing. They can do this kind of varying things, randomly trial and error and kind of figure out how they're generally good at making API calls and sort of failing a few times and then succeeding. The thing that I think we're going to hopefully ship fairly soon is this capability to crawl an API where you give some initial information and it will go and essentially generate a recording, which ultimately turns into a mock and an open API that was generated by the AI just kind of exploring the API on your behalf. Kind of automating that, that process that you'd otherwise be doing by hand. And I think that could be really promising. I think, again, this sort of just, it's this grunt work that you have to do as a tester, as a developer, when you're building up test infrastructure, and when you are building test fixtures, generating data, understanding the mapping things out, I think it's a great use case for AI to automate that stuff so that you have this kind of good quality information and good quality test fixtures built for you that you can then do the kind of higher value actual testing work on top of.

[00:34:07] Joe Colantonio Is this open source the MCP server or are there pieces that aren't?

[00:34:10] Tom Akehurst It's not open source. It's part of our CLI, which is, it's free. There's a free plan in the cloud product, you can just kind of sign yourself up to it and use it with that. You can install it from NPM and it's pretty straightforward. So definitely worth a try.

[00:34:26] Joe Colantonio Exciting times, for sure. All right, okay Tom, before we go though, is there one piece of actual advice you can give to someone to help them with their mocking automation testing efforts? And what's the best way to find or contact you?

[00:34:36] Tom Akehurst I'll answer the easier question first. Contact I'm on LinkedIn, you can get in touch with me personally on there. WireMock has a company page on there as well. You can join our Slack community. That's slack.WireMock.org. It's linked to all over our websites. Easy enough to find as well. And my software engineering team hang out on there, I would say, if you want to get started mocking, then start small, but with something high value. Application that you're testing, so even some particular dependency in it, which is just a pain to work with where you have an unreliable sandbox where your test runs keep flaking out where you're finding yourself having to leave the test runner going over the weekend because it takes so long, you don't find that really sort of high value thing where you think I wish I could make this fast and reliable so that I'm not constantly rerunning these same tests over and over again, just to get to green and focus on doing that and building out from there. I suppose don't get into the mindset of thinking I have to mocks across the board. Otherwise it's not worth doing. There's nothing to stop you as I blending them in with integration testing, integration testing strategies. And I know you only asked me for one thing. There's one other thing that's worth me saying as well, which is try to be intentional in thinking about what, when you're testing something, like what risks are you really primarily looking for? Because I think some people just integration test everything essentially, and within that integration testing, sometimes they are specifically looking for, the thing I'm testing, is it functionally correct? That's the kind of primary risk. And then sometimes there's a lot of risk around, does it integrate correctly with its environment? And the two kind of get blurred together. It's all just one sort like I'll do some things and then something will break and hopefully I'll see it. But if you can separate that, if you can say, this test, I believe, is about functional correctness of the thing I'm testing. That's a great candidate for, right, I can mock everything really aggressively. And that means I can have fast tests. I can explore the space a bit more cheaply. I can run my build faster. And to be honest, if do this well, they've become the majority of your tests. And then you have this remainder, which what are the things where there really is genuine integration risk that mocking might mask? And then you have this kind of minority of tests that you run just to kind of manage at risk. And I think if you can do that, then you can, it will just make your life immensely easier. You'll be utilizing your sort of integration testing time and effort, all of that kind of high effort stuff, just to focus on the risks that it's really, you're going to ideal for, and then you're doing the fast, easy stuff the rest of the time.

[00:37:23] Joe Colantonio Great advice, Tom. And as always, you can find all the links for all this awesomeness down below.

[00:37:28] Thanks again for your automation awesomeness. The links of everything we value we covered in this episode. Head in over to testguild.com/a550. And if the show has helped you in any way, why not rate it and review it in iTunes? Reviews really help in the rankings of the show and I read each and every one of them. So that's it for this episode of the Test Guild Automation Podcast. I'm Joe, my mission is to help you succeed with creating end-to-end, full-stack automation awesomeness. As always, test everything and keep the good. Cheers.

[00:38:02] Hey, thank you for tuning in. It's incredible to connect with close to 400,000 followers across all our platforms and over 40,000 email subscribers who are at the forefront of automation, testing, and DevOps. If you haven't yet, join our vibrant community at TestGuild.com where you become part of our elite circle driving innovation, software testing, and automation. And if you're a tool provider or have a service looking to empower our guild with solutions that elevate skills and tackle real world challenges, we're excited to collaborate. Visit TestGuild.info to explore how we can create transformative experiences together. Let's push the boundaries of what we can achieve.

[00:38:46] Oh, the Test Guild Automation Testing podcast. With lutes and lyres, the bards began their song. A tune of knowledge, a melody of code. Through the air it spread, like wildfire through the land. Guiding testers, showing them the secrets to behold.