About this talk
This talk is presented by Tuma, a QA engineer at SideGround, who discusses the importance of mock proxy testing using WireMock. He shares his experience of encountering issues with third-party API dependencies that led to test failures during automated builds. Tuma introduces WireMock as an open-source tool for API mocking and service virtualization, emphasizing its benefits, such as being free, stable, and easily integrable into existing testing workflows. He explains how WireMock allows for isolated unit tests, integration tests, and performance tests by simulating external APIs and defining predictable API behaviors. The speaker demonstrates WireMock's functionalities, including stubbing, response templating, and the ability to simulate errors, providing insights into its practical applications at SideGround and offering a live demo of mocking a payment provider to enhance testing efficiency.
Full transcript
Thank you for the introduction and hello everyone. Thank you for joining me today. My name is Tuma and I'm very excited to present on a topic that I truly believe can significantly improve your testing strategies. Mock proxy repeat elevate your testing with wire mock. So I have been a Q engineer for about seven years now and I currently work at side ground where I do both manual
and automated testing and last year was actually my very first time here at ISA but uh I was upstairs at the lobby at our side ground tent at the booth where I would say I've met a lot of amazing people. It was great. We talked, we laughed, we had fun, we played games. There was even this magician, a colleague from another company that did some magic car
tricks with me. So to be honest, I never imagined that a year later I'm going to be standing here on this stage and talk about API mocking. But I guess this is what is about, right? It's about sharing knowledge. It's about sharing experience and connecting people, connecting professionals. So let me tell you how I got here. A few months back I didn't know much about wire mock
but one morning at the office we saw that there were like a lot of tests failing in our nightly automated builds and at first we thought that the reason is with us like the issue is somewhere in our code but after carefully analyzing the results we found out that actually the issue was external one and we were dependent on a third party VA validation service that at
some point started working slowly or it wasn't working at all like the API the the API was down or at some point it was even rejecting any input without no reason. So in order testing not to be blocked and testing processes to go smoother, we decided to mock this external API to create a mock API that looks and behaves exactly as the real one. So, I had
to fix this and I had to quickly learn how to work with Wiremok. And here I am, long story short, sharing with you how Wire saved us countless hours of stress. So, what is actually Wiremok? Wiremok is an open source tool designed for API mocking and service virtualization. It supports HTTP based APIs and it allows you to have full control over the API behavior and simulate responses
for testing purposes. So don't get me wrong, I know you going to ask why w why wiremock? Why why not something else like why not any other tool? Well, the short answer is that I didn't choose wire mock but the problems we faced chose it for us. So when I joined this side ground team wire was already established solution and we continue using it because of three
simple and very pragmatic reasons. First, wire moach is free and it is stable and it has huge community and it is constantly updated. And secondly, wiremok solves our specific pain point. As you're about to see, we had huge and big headaches with a payment sandbox. And not at last, wire mock is simple. It easily integrates with our testing stack and it can be easily configured and overall
you just basically can get started easily with wire mock. So something else might fit better in your project. But I'm here just to show you how wire helped us to gain control over our dependencies. So the main idea behind wiremok is to eliminate any dependencies from thirdparty services from any live services or external APIs that your application is using. So you can use wire mock in unit
testing to isolate the code being tested. You can use wire mock in integration testing to simulate the external APIs and check if your application interacts correctly with them. You can use wire mock in performance testing like simulating different faults and errors, timeouts and delays and check how your like it performs in different conditions or you can use wireok in end to end testing and even edge cases
and scenarios that are hard to hit and reproduce on life and production environment. So wire mock gives you flexibility. It's best for complex scenarios and wireok speeds up testing. Test execution becomes faster. Later you'll see an example how saving a few seconds here and there when you have thousands of tests. The impact is huge. So wire brings also stability. Tests are less flaky because you have predictable
and reliable API behavior. And wiremok lowers the maintenance efforts. As I said, it enhances your test coverage and wire optimizes the resource usage and not at last wire can be easily integrated let's say with CI/CD. So I was talking with a colleague from the dev team and I was explaining to him what is actually wiremok and after a few minutes he just decided to Google it and
he said like why didn't you just say that wiremok is a web server. So okay yes wiremock is a web server and to be more specific it is a mock http server and this is how it looks when it's up and running. By default, it runs on port 8080. It also supports the secure one. And uh there are many ways you can use wireok. You can always
go and use the cloud version of wireok. Uh you can use the standalone version of wireok. You just have to have java installed on your machine or uh you can use wmok as a library. But the way we leverage wire at side ground is using it with docker. So basically you just have to execute a docker command that will automatically pull the latest wire mock image from
the docker hub and install it locally on your machine and store it in the docker cache. And at side ground we've mocked a lot of APIs, a lot of thirdparty services and external APIs that we are using and we are working with. I already mentioned about this uh VA validation system but we've mocked some of the payment providers that we are working with and we are using
and later I'm going to do a quick demo for you how and why we've mocked a critical payment provider and we've mocked even some of the Google APIs and we've mocked many many internal processes and services. So how does actually Wiremok works? Let's check this workflow diagram. As you can see, wire mock stands in the middle. It acts as the middleman between the client application and the
external API. So what happens is that the client application sends an HTTP request which we proxy to the wire server which is up and running. And what does wiremoke do is that it goes and checks if there are any STOs or configurations saved for this particular HTTP request and if it finds one it matches the request and then wire mock returns the mock API response back to
the client application. Basically it returns the simulated API response. But if wire moach doesn't detect any step or configuration saved for this particular HTTP request, it acts just as a proxy and it proxies the request to the external API which from its side forwards back the response to wire mock and then wire mock returns the API response to the client application and the stubs are the actual
mocks. Stubbing is a key feature of warmok. Stubbing allows you to have predefined HTTP responses for request matching criteria. And how do you create a stup? Well, for the sake of this example, I've used Postman just to have better visualization. And uh don't get me wrong, here we are creating a stepover API. So how do you create something with a post request in our case to the
local host on port 8081 where actually wmok server is up and running and to the admin mappings folder. At the mappings folder all the stops are created and stored and here we are creating in this in this example a st for a get method with URL side ground client one. So it's very simple one and it just returns status 200 and body message saying millions of happy
customers get better website presence with us. You can too. And once you click on the send button you can see that the ST is successfully created and it looks exactly as we wanted. wire just added to it a unique ID and uh once again we created this step over API but don't get me wrong as you can see it's just a simple object is nothing more but
just a JSON so we can always navigate manually to the mappings folder and create it by your own like manually but how do you test if this step works well you go and make a call to the side ground client one endpoint and when you hit on the send button you receive the exact same response with status 200 and same body message. So in similar fashion you
can create steps for post requests and etc. But what happens when wiremok doesn't match a request. Well as you can see in this example we are proxying to the wire server a request about side ground client 2. But we don't have such a step. As you already saw in the previous slides, we created a ST for client one and wire detects does the closest step, but at
the end the request is not matched because URL doesn't match and matching on URL is like one of the most common ways for wire mock. You can match on exact URL path or you can match on URL path pattern like where you can use even regular expression and that can be actually very powerful and later you'll with using regax you can simulate let's have you have uh
let's say you have thousands of clients and users but you can match on many other attributes such as content type and just valid XML or body patterns and valid JSON or you can even match on uh the basic authentication attribute with any particular username and password. But if you're kind of not satisfied with the standard set of matchers that wire provides, you can always go and create
your own one. So it's pretty much simple and straightforward. You just have to extend this request matcher extension class and I've named this uh custom matcher body length matcher. It's very simple one. It just returns body to long and this is how the stuff for it looks like once it is created. It has only one parameter and it's for max length. So it's like imagine you are
testing and verifying an input field or any text area for max allowed characters and when you input when you enter more than the allowed characters you're going to hit this validation error message and wire mock will return and match this step and we return the mock API response for it. But this is just a simple example how you can customize something in Warmock. You can customize a
lot of things. As for example, we've created this uh helper helper function that just uh extract uh some valuable info for us from a JW token. But you can also have uh like this uh uh request filter extension or even response transformer And here comes the response templating. So this is another core feature of warmok and response templating gives you the ability to have dynamic responses. So
what happens is that you can basically can take values from the request being sent and use them in the response. So here is where the URL pattern and the regular expression kicks in. So imagine this reg x is our client ID. So we have side groundclient slashclient id. So it can be anything corresponding to this regular expression of course. And as you can see in the response
for the ID we take it from the request path. But at the end the client will be always one and the same with first name Tom and last name Aers. And below you can see that the ST is created. And if you go and try to test it out well ABC5 in our case is the client ID but as I said it can be anything else. and
we take it dynamically and use it in the response. So you can see that in the response we have the exact same desired ID ABC5 but as I said the client will be uh hardcoded and always one and the same Tom Ahertz who is actually uh like this is not a coincidence that I'm using this name Tom Ahertz is a very popular name at the Wmock community
uh because uh he is the original creator and currently CTO of Wmock and How can you simulate faults and errors? Well, it's very simple. I've created this failing API. It just returns 500 server error. So, if you go and try to reach it out, you receive the corresponding 500 server error. And in similar fashion, you can simulate timeouts and delays. You just have to add and use
this fixed delay in milliseconds. 5,000 in our case which stands for 5 seconds and uh if you go and try to reach this slow API at the above screenshot you can see that like the request is being sent like it's a continuous action you're not receiving the response immediately but on the below screenshot you can see that exactly after 5 seconds you receive the delayed message and
I've showed how you can create STOs over API or I told you that you can just literally navigate manually to the mappings folder and create them by your own but actually there is no need to do to do all that because wireok gives you this powerful recorder. So this is how it looks. It has very simple UI. You can open your browser and navigate to the admin
recorder and you just have to input a target URL and hit the record button. So in our example I have used wireok cloud API as target URL and once wire goes in recording mode what happens is that we have to go and do a call to the target URL and wire mock will record for us the response and we will automatically create a step for us. So
don't get confused here. The local host on the secure port is basically where Wiremok server is up and running. And imagine this is your target URL. This is the Wiremok cloud API. And the recordables one, two, three is nothing more but just a test endpoint that returns congratulations on your first recording. And when you go back to the recorder and click on stop button, you can see
that wire mock captured one st mapping successfully. So wire mock created and recorded for us this exact step. It's exactly the same with same status 200 and same body message. Congratulations on your first recording. And wmok gave it a name wiremok recorder example. So it is that And now it's a time for a short demo as promised. And as I told you at side ground, we've mocked
a lot of external APIs that we are working with and we are using. But uh I'm going to show you how provider. So let's see first how things work when wire mock is off. Wire mock is not running. And in this example, I'm just making a simple order from our side ground site and I'm ordering a hosting plan with a domain. But pay attention that when you
click on pay now button, what happens is that we're basically connecting with the test sandbox provided to us from the banking API. And because I'm using this specific test credit card, the so-called 3D secure challenge page is triggered. And we have to complete this challenge. And after that, for some of you, if uh don't know what's 3DS, it's just like your digital signature that identifies your SD
card holder. And after that, you can see there's around 10 seconds of blank page until you're navigated to the success screen and the transaction is completed successfully. So you can see how slow things work and how unreliable and unstable they look like. So what happens if tomorrow this test send box doesn't work like it's down or let's say there's an issue with the test credit card and
I assure you this happened not once or twice but many times so there is no need to be dependent on that and now let's have a look how things work when wiremok is up so we have configured our systems so So that all the requests from the all the payment requests go through Wiremok and Wire compares them against the STS that we have and instead of forwarding
the request to the real payment sandbox, wire mock returns the mock success API back to the side side ground application and side ground application thinks that it has connected successfully with the payment. on sandbox, but we all know that that that's not true. So, basically, we bypassed this whole process and we didn't saw like this 3D secure page with a challenge, this around 10 seconds blank uh
blank page. We were instantly navigated to the success screen and the transaction was was completed just in milliseconds because wire mock returned the simulated success API response and this was the exact step that was matched. We matched on body patterns and this exact test credit card that I've used with last four digits 3155 and the CBC doesn't matter. It should be anything different than three nines. And
you can see that even here you can use regular expressions and it should be case insensitive false. And uh during this whole transaction process that was not the only step that was matched and Vmok matched many other requests because first we simulate attaching the payment method with 3DS to the customer. Then we initiate the payment intent with 3DS. Then we confirm the payment intent. Then we get
the payment intent details. We capture the transaction and finally we confirm that it is successful. So in conclusion I would say that wire mock brings efficiency to side ground. It speeds up testing. Test execution becomes faster. And as I said imagine is huge and wire brings stability. Tests and wiremok lowers the maintenance efforts. It enhances the test coverage where you can test even edge cases and scenarios
that are hard to reproduce on live and production environment. WMO gives you optimized resource usage and not at last WMO can be easily integrated with CI/CD with Docker and So don't get into the trap of uh unreliable APIs. Get things in control and start mocking if you haven't yet. Thank you all. I'll be happy to answer to any questions if there are any or if we have
any time left but we can always chat after the presentation even. So thank you. >> Thank you and we're waiting you in literally 10 minutes.
