WireMock with Tom Akehurst

In a land of testers far and widely journey seeking answers, seeking skills, seeking a better way. O the Testicular Nation Testing Podcast Guiding testers with our nation awesomeness.

From ancient realms to modern days, they lead the way.

Oh, the Testicle Ovation Testing Podcast.

Hey, Want to know more about open source API mocking and how it can help you with your 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 Wiremock Cloud, where he's helping complex engineering organizations unlock productivity gains by adopting API simulation techniques at scale. I think it's a 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 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 backend services during development and testing. Additionally, 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 that fits seamlessly into your existing workflows so 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, SLE's, SOC2 compliance reporting and analytics and role 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 4.3 out of 5 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. Hey Tom, welcome to the Kilt.

Hey, thanks for having me on.

Great to have you. As I mentioned in the pre show, I've heard of Wiremark 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 Wiremark and where have you gone now? I think you've done other things now at Wiremock Cloud and what is that?

So yeah, I've been working on Wiremock open source for about 14 years. And the thing that originally sparked it, I was working as a consultant for a long time and I was working on projects that often involve kind of complex integration problems. You know, service based, microservice based. And I was working on a, a particularly large. It was sort of pre microservices, 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, in kind of distributed enterprise environments like that. So I ended up building the tool just as a, 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. So it started out that way.

Love it, love it. So what's it evolved 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 or the foundation that you created.

Yeah, so I mean it's evolved a lot over the years. I mean the core fundamentals of Wire Mock is that it's an API mocking tool. So by that it's 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. So you're, you're 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. You know, it sort of can't tell the difference. And crucially, that means you're sort of testing your, your real production code in terms of the code that integrates that your app with your dependent APIs. And the fundamental building block is this kind of stubbing is request response pairs. So 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. So there's been the addition of dynamic templated responses. So 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, you know, dates, they're sort of one of my favorite topics. If you, 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, there's all that kind of stuff. And then there's been extensions built for other protocols. So we've got, you know, 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 O or, you know, OAuth type workflows and generate signed tokens, then you can do that. So it's, there's kind of a whole host of stuff. I mean, I could keep going and going. I should probably pause at this point.

No, no, I love it. I guess, you know, 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 and API versus the full integration test?

Yeah, absolutely. I mean, I have a very sort of biased view of this because I spend, you know, all day, every day practically kind of talking to people who are, who have either made this decision or they're thinking about Making this decision. I mean, in a way it surprises me how many people you see still not making the decision to use mocks and who, you know, they take the view that they're not trustworthy, that they, you know, if you use mocks then you're, you're running the risk of kind of producing false positives in your testing and that that's just going to push, you know, maybe even all the way into production the point where you discover integration bugs and so on like that. So there's kind of a, 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, 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. Yeah, I mean wire mock open source is very well designed for that. I mean it has a, a rich Java dsl, you know, allows you to sort of, to work that way very expressively. But I think that, yeah, there's then this whole spectrum of additional ways you can deploy it and get value from it where, you know, you can deploy kind of like a sort of outer shell of mocks around a whole set of, for instance, microservices that you're testing together. So you know, 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. You know, so everything is being provided by their partners, their SaaS, vendors, all of that kind of stuff. But then they'll integration test the bits in the middle that depend on that sort of outer shell of APIs. And yeah, there's, it isn't one size fits all. You know, 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. So yeah, there's definitely a, you know, it requires a bit of thinking and understanding the trade offs, I think in order to, you know, to use it well in that regard.

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?

Yeah, that's a good question. I think you definitely see people who are, you know, Sort of overly keen to sort of push it into every, you know, 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, 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, you can mock outside of them and integrate them. So there's definitely that. I think there's also sort of how people choose to design the actual mocks themselves and how they, how they maintain them is I probably see people making more, more mistakes or sort of suboptimal choices, I guess, in, in, in that regard, you know, where people will, you know, for instance, try and use record and playback for absolutely everything and not have a strategy for, for generating or enhancing stubs that's a bit more sophisticated. So they create this huge maintenance burden, kind of recording hundreds or thousands of requests from all of their APIs and then having this problem, you know, problem of sort of constant obsolescence in them, you know, where they, they're having to sort of rerun and recurate and recheck these things all the time. That can definitely be burdensome.

Makes sense. So I always have a, with these class of tools, I'm always. They always have a lot of awesome functionality. And maybe I'm wrong. Maybe sometimes I think they get, they get looked over because, you know, 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 almost bridges the gap between the two. Maybe I'm wrong. Do you see this then as a developer productivity tool or does it offer test coverage, benefits and who should be using it?

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 got 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, yeah, 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, you know, 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. So it's definitely productivity enhancing there because it's 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. So whether you want a test case with a simple sort of single record being served from an API, or whether you want one which has got, you know, 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 see with test data. And, you know, 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, they're high effort. Likewise with kind of injecting faults and so on like that, you know, it's just as easy to mock a fault as it is. It's sort of a happy path case. Whereas in integrated tests, you, you know, 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, to get them to reliably produce errors. And then they're doing it for everybody, which is not so great. So being able to kind of say for, if you, yeah, 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, I can very easily establish how my application under test behaves when I see that fault. But I don't have to do all this kind of disruptive work in order.

To discover that 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, all right, how does it handle gracefully when something's down or the service isn't available?

Yeah, absolutely. I mean, there's a whole. Wymock 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, you know, 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. So those kind of things that happen when again, like if you're in a microservices environment and your system's under pressure and, you know, web servers are starting to kind of brown out, they're not completely failing, but they're sort of, you know, dropping connections for some requests or failing in ways that, you know, that are kind of happening at the infrastructure layer. Then you can test those things very easily. And you can do it. You can either do it deterministically or actually, and I'm plugging slightly here, but in Wiremock Cloud there is also a chaos mode that is kind of a randomizer for that. So you can, 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 SOAP test or something, you 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, you know, sort of have to be restarted from the ground up to make it work again?

Absolutely. How realistic shot mocks 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, does it. It depends, I guess.

I don't know. Yeah, it's definitely a depends one, but I suppose one, one there were. There's a few heuristics that I'd use to determine that. I think a key one is kind of this thing about, you know, the context in which you're deploying your mocks. So I think when you're, 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 transition or 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. You know, generally that's good enough because you're like I say, you're kind of examining this very small Specific controlled transition. Often, you know, where you, you have kind of full control over all of the, you know, the input data and everything else. If you go to the other end of the scale where you're often, you know, so if you're the situation I described earlier where you've got maybe a bunch of collaborating services and you're, you're testing sort of at the feature level, so 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, you know, 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. So the, the most common thing we see, and this is something we, you know, we've been building quite a lot of stuff around recently, is statefulness. So being able to capture data from one request or one interaction and, and then reuse it in a subsequent one. So then you avoid the situation where you get these weird apparently glitchy behaviors where sort of all of the API calls have been made correct. 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. So I think there's, if you're trying to model these sort of coarser grained interactions and you know, the things which are closer to what the thing you're testing is closer to what the end user is experiencing, then realism is more important. Whereas if you're, if you're down near the code then it's less important.

So 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.

So yes, it does happen. I, a few years ago I was, I was doing performance engineering work for a big retailer over here in the UK and, and they, they had a typical kind of, you know, they made all their money on Black Friday and, and so there was loads and loads of preparation, loads of performance testing and performance engineering work would, would happen in the lead up to it and they wanted to do as much testing and production as possible. So they had a, essentially their integration with their payment gateway had this bit of logic in it that said if the person doing the paying had a certain email, magic email domain or something like that, it would route the payment request to, to a wire mock, mock instead of the real payment gateway. So then the load generator would only generate customer emails with this, this magic domain in there, which meant that all of the payment, payment requests would go off to a mock instead. So that way they weren't sort of attempting to hammer, you know, whoever their payment provider was. Gateway. Yes. Sandbox. Sorry. You know, payment gateway. I'm getting totally. Because the thing with payment gateways, right, particularly the older ones, is their sandboxes are not, 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, more realistic, but you can still exercise the rest of the, the production system. So I've seen examples like that a few times. I've seen a few slightly more esoteric ones as well, I guess. I mean there was a company we spoke to a while ago who were kind of, they were kind of doing this hybrid thing where they, they were using it for diagnostics. So they were sort of capturing a mock of real interactions out here. So if something went wrong in their production system, it was kind of snapshot, a bunch of API interactions, turn it into mocks and then you could sort of take it back down into your development environment, but with this, like I say, this sort of snapshot of the state of the production environment that you could debug in. And I thought that was a, that was a really cool idea.

Yeah, that's really, I could see that being really helpful, especially before open telemetry and all that.

Yeah, well, I mean, it's something, one of those things I haven't had time to explore really, but would like to, you know that being able to, to hook into things like open telemetry, you know, because they could work really well together. You know, if you could, 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 yeah, you know, it's kind of made for it, right. You know, you just grab all this stuff out of the ether and run some, you know, translation scripts over it and you've got a ready made, you know, shrink wrapped environment that replicates a problem, which is kind of a. And a lot of environments is like testers, you know, is gold for testers.

You know, Holy grail. Yeah, yeah.

I love it because the effort involved is so high in getting to, you know, what do I need to do in order to replicate this bug? You know, so much of us have spent so much, so much time in our careers trying to figure that stuff out that if you can just kind of automate it, then, you know, it makes you so much more productive.

Yeah, I might try to vibe code, something like that. That's a, that's an awesome use case. Awesome. So I know that there are some downsides or I hear 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, and make a big deal out of it. So how do you recommend, is this a real deal API drift? And if so, how do you recommend teams handle. Handle it?

It is a real problem. I mean it's, it's something that we, again, we talk to customers about a lot because the, they want to use mocking at a scale where it becomes a really acute problem. You know, microservice environments, it's, it's a particularly severe problem because you've got lots of APIs that are very, you know, in a very high, high sort of state of change. You know, they're being constantly having new things shipped to them, constantly changing and the, the speed at which you're, you know, if you've created a mock just sort of, sort of at a, 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, you know, months and months worth of changes. Then, you know, the two will diverge very quickly and the, you know, hopefully fairly obviously the sort of resulting confidence that you can get from the, from your mock will go down because it's, because it's diverged from reality. So this is, this is definitely a big, a big issue. And the, you know, the things that we've been building and we've been exploring in order to mitigate that are kind of use it. Yeah. Primarily using forms of contract testing, I guess you'd call it, not, not the kind of like sort of packed style of consumer driven contract testing, but kind of, it's really sort of traffic validation using open API primarily and that kind of technique. So making sure that there is a, you know, there is a, some, some sort of source of truth describing what the, the API's contract is and then making sure that while you're using your mocks, while you're running them, that you're also validating against that contract. And so, you know, for contract changes, then you can, for instance, fail your CI build. You know, you can, you can return an error and then get this sort of quick feedback that, you know, your mock and your contract are sort of out of compliance with each other.

Yeah, I was actually going to ask you that as you were talking about contract tests and if you can use it to guard against contract violations. And it sounds like you 100% can. Nice.

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 APIs, 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 usage, there are things that are just outside the scope of what you can describe with open API. So it's not, it's not perfect by any means, but it's certainly anything, all the obvious kind of, you know, structural things about APIs that you're, you know, that just routinely get broken over and over again as, as, as APIs evolve, you can, you can very effectively cache by kind of using these techniques. Maybe I'm going into too much detail now, but there's, there's a couple of different approaches you can take for this, that, that, that, that we sort of observed and try and facilitate. And there's, which is one, there's, there's using open API when you've kind of adopted it widely as an organization. You know, if you have already, you already have kind of good habits around documenting your, your APIs and maintaining those documents and kind of publishing them somewhere in a way that means that people, yeah, people can get, you know, can get up to date versions of the, the, the contract and they, they can detect when they, when a change has happened and all that kind of thing. So if you can do, if you do that, then that's great, that's gold. Because then you can take that, that contract that the, ideally the producer of the API is making and you can just keep constantly validating your mocks through it. You know, so you'll get a, a really sort of, you know, high validity, sort of fast feedback about whether your, your, your mocks are valid. But failing that, you can also take a, a kind of, you can, you can build your own contracts of other people's APIs. So you can. Yeah, the other thing we support doing in cloud is you can make a recording so funnel Some traffic through to an API and we will build an open API document for you while you're doing that. So if there are, you know, 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.

So it's auto generating a mock based on the spec is how that works.

So we can go both ways. So you can, 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, or you, and you can kind of, you can kind of iterate between the two as well. I mean, this is a whole other deep topic that I get a beer in my bonnet about sometimes and try to explain briefly. I mean, they 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 they don't. And in a nutshell, open API says more about the API. Structurally, it'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. So a mock, you know, you can go and hit it with different combinations of parameters, and provided those things have been, you know, these behaviors have been defined, then you can see how, you know, 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 open API. So the sort of, I guess the approach that we advocate for is not, not sort of saying, 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, in a spec. So 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 richest set of information by combining the two about how, how the API is supposed to work. And, and then obviously you then have the, the greatest set of opportunities to know whether you're Doing the right thing or not.

Great advice, love that approach. So I'm also thinking as you're talking, no, 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 ChatGPT or things like that?

So yeah, we, we built a mock of ChatGPT. Actually. We, we, we did, we did one and put it in our, our marketplace. Marketplace. We have like a library of pre built mocks and so we stuck it up there.

Oh, cool.

Yeah, a few people use it. It's, you know, if you, if you want to be able to kind of get deterministic responses back, you know, if you're, if you're building an app and you know, you want to do sort of, you know, 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, we, I mean, in some ways an AI is kind of an accelerant of all of the problems that mocking is good at solving. So people want to be able to generate code faster and they want to be able to generate code which is correct and valid and sort of tested to some, you know, meaningful standard. Yeah, and they want to do that with AI. You know, now, you know, all of the, the coding tool providers, or a large number of them at least seem to be going in the direction of these remote agents, which. Yeah, so that you're, you as a developer are kind of managing this farm of tens, dozens, whatever of these, these remote agents and all of that, you know, creates more of the kind of problems that already existed. So, you know, 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, you know, your privileged infrastructure. I mean, this is a, an increasing problem that we're seeing is particularly like microservice developers. Again, you know, 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 can, you've got a bunch of test environments that you can talk to, so 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 you know, shift it into an AI provider's public cloud which has no privileged access to your network, then that's, yeah, that's not really an option anymore. You know, you've got to find some other way of providing the dependencies that you're, the code that you're, you're generating testing needs. So I think there are things like that where the, it's sort of creating new, new ways to experience the old problems. And I think the other interesting topic, and again, this is something that we're, we're sort of actively exploring and trying to figure out the, you know, the essence of and where the edges are, is, is this kind of, this notion of feedback loops and guardrails and so on. So a lot of AI based code engineering I think at the moment is looking at how to use, you know, these techniques that provide external validation and feedback for the correctness of the thing being generated. And you know, ideally in a way which is sort of automated and automatable so that you don't need human beings doing it. And you know, mocking provides some really interesting opportunities here. I mean, the contract setting, 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 they fail, go and look at the validation reports that the mock tool gives, go and look at the telemetry inside the mock tool and then figure out what went wrong. And you know, by having that, they've got far more detail about what the, how the code behaved, you know, 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. So the ability to sort of play, you know, use mocks as this, the. Yeah, this sort of point in a, in a feedback system that coding agents can use to iterate towards a correct solution. You know, I think there's, there's a lot of sort of potential power there. You know, we're sort of starting to see how, how this can play out.

All right, Tom, everyone seems to be having, releasing an MCP server. Any information on whether or not Wire mock is going to have an MCP server or do you have one already?

So, yes, of course, like, like everyone else on the planet, we now have an MCP server for our product. It's. Well, I guess no one's MCP server is particularly old at the moment where ours is relatively new, but we, it's already allowing some really interesting use cases to emerge. The great thing about being MTP and plugging into AI coding assistants is that you can kind of do these, these sort of composite changes. So you can ask the coding assistant to generate tests and then generate the corresponding mocks also, kind of, as I alluded to earlier, you know that you can, it can interrogate the telemetry from the MOP and feed that information back into the coding session, all of that kind of stuff. So we can already do all of that. I mean, it's great just for kind of, if you want to generate more test data or more examples, it kind of takes away so much of that grunt work of, you know, I've, maybe I've recorded this one API call, but Now I want 10 more different bits of data that kind of are similar but, you know, 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. So it's, it's great for doing that. And, and we're experimenting with some slightly more interesting use cases with it as well. You know, the, the, the, the one that I'm really interested in at the moment is using it as a crawler. So kind of one thing that I, you know, I've observed a lot and I've done a lot when, when you, you have an API that you want to integrate with as a, as a, as a developer, and I think obviously testers end up doing this a lot as well. When, when the thing being tested is an API, you kind of get given this partial information about it. You know, you get some documentation or maybe somebody says to you, oh yeah, here's, here's kind of a rough idea of how you call this thing, but you don't, you don't necessarily have complete information about it. And you know, you, I mean you certainly don't have a fully working mock, even if your information's pretty good. So then you get, you know, 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, 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 the, you know, this, this is a perfect use case for, 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, and you know, kind of Figure out how to, you know, they're generally good at making API calls and sort of failing a few times and then succeeding. So the thing that I think we're going to hopefully ship fairly soon is is this capability to crawl an API where you get, you give some init and it will go and essentially generate a recording which ultimately turns into a mock and an open API that was generated by the, you know, the AI just kind of exploring the API on your behalf. So kind of automating that, that process that you'd otherwise be doing by hand. And I think that could be really promising. I think the, again, this sort of just this, this grunt work that you have to do, you know, as a tester, as a developer, when you're building up test infrastructure, when you're building test fixtures, generating data, understanding the, you know, 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.

Is this open source, the MCP server or are there pieces that aren't.

It's not open source. It's part of our cli, which is free. You know, there's a free plan in the cloud product so you can, you can just kind of sign yourself up to it and use it with that. It's, you know, you can install it from npm. It's pretty straightforward, so definitely worth a try.

Exciting times for sure. All right, Ktown, 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?

I'll answer the easier question first, so contact. I'm on LinkedIn so you can, you can get in touch with me personal personally on there. Wymock has a company page on there as well. You can join our Slack community. So that's Slack.

It's linked to all over, all over our websites. So easy, easy enough to find as well. And I and most of our engineering team hang out on there. I would say if you want to get started mocking, then start small but with something high value. So find some, you know, application that you're testing so even, you know, some particular dependency in it, which is just a pain to work with. You know, where you have a, an unreliable sandbox, where your test runs keep flaking out, where you, you're finding yourself having to leave the test runner going over the weekend because it takes so long. You know, find that really sort of high value thing where you think, I just, 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 be, don't get into the mindset of thinking I have to, I have to have mocks across the board, otherwise it's not worth doing. Because I think you can, you know, there's nothing to stop you like blending them in with, with integration testing. Integration testing strategies. And I know you only asked me for one thing. There's one, one other thing that's worth me saying as well, which is try to be intentional in, in thinking about what, when you're testing something like what risks are you really primarily looking for? Because I think the. Some people just integration test everything essentially. And within that integration testing, sometimes they are specifically looking for, you know, does my, the thing I'm testing is it functionally correct? You know, that's the kind of primary risk. And then sometimes there's a load of risk around. Does it integrate correctly with its environment and the two kind of get blurred together. It's all just one, one sort of, you know, like I'll do some things and then, you know, something will break and hopefully I'll see it. But if you can sort of separate that, if you can kind of say this test, I believe is about, is about functional correctness of the thing I'm testing, you know, that's a great candidate for. Right. I can mock everything really aggressively. And that means I can have a, I can have fast tests, I can explore the space a bit more cheaply. You know, I can run my build faster. And to be honest that, you know, those, if you do this well, those become the majority of your tests. And then you have this remainder which are like, what are the things that, where there really is genuine integration risk that mocking, you know, might mask. And then you have this kind of minority of tests that you run just to kind of manage that risk. And I think if you can do that, then you can, you know, it will just make your life immensely easier. You'll be, you'll be utilizing your sort of integration testing time and effort, all of that kind of high, high effort stuff just to focus on the risks that it's really, you know, ideal for. And then you're doing the fast, easy stuff the rest of the time.

Great advice, Tom. And as always, you can find all the links for this awesomeness down below. Thanks again for your automation awesomeness. The links to everything of value we covered in this episode head on 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. 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. 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@testguild.com where you become part of our elite circle driving innovation in 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 test guild.info to explore how we can create transformative experiences. Together. Let's push the boundaries of what we can achieve.

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 tester showing the secrets to behold.