We spent enough years using the old ways of mocking. You know well that adding JSONs to your code is not the best solution, but what can you do? Everyone does it like that, right? Well, not anymore! Buckle up, and check out how you can mock in a better way from now on!
What is mocking
Mocking is a developer tool that allows you to simulate the behavior of real objects in your code. It's a way to test your code without using the data it typically needs.
This can speed up development since you don't have to wait for a response from an external source before continuing. It also reduces the number of errors since the mock is always predictable and consistent. Finally, it allows for faster deployment because everything is already tested and ready to go!
Mocking is a powerful tool that has been around for quite some time (since 1996!), but it's only recently gained popularity as a developer tool. Developers are increasingly recognizing the benefits of mocking, and many are starting to incorporate it into their workflow. It is something that can really speed up development and help you catch errors early. But it's also traditionally been hard to do, requiring lots of code and time spent writing tests.
For example, if you're building a website with a database backend, you might have to wait for the database server to be ready before your site is prepared for users. But what if your site has lots of different databases? You could end up waiting hours or even days for every one of those servers to be ready before your site is ready!
Mocking on the frontend side
A lot of developers have been doing mocking on the frontend side for a long time. It's a simple enough process: you copy and paste some JSON into your codebase, and you can test that your code will respond correctly. This is pretty fast to do.
The problem with this approach is that it doesn't really tell you how your code will behave when it's running in production. What if the API data changes? What if there are errors? What if something goes wrong on the server side? You haven't even coded the request handling because you only have a static JSON in your code.
But it's what we've done for years! The problem is that when you do this, you're making your tests much slower and less reliable. It's also a pain to do if you have a large number of requests and you are trying to test for different scenarios.
Another problem with this approach is that it doesn't allow us to test our codebase in a controlled environment where we can control what data comes back from each request or how many times something happens before moving on to the next step in our tests—which means we could end up testing against invalid data or something else.
If you're building a web application, it's essential to ensure that the frontend and backend are working together as efficiently as possible. To do this, you need to ensure that both sides' code is as similar as possible.
How can you test/demo a different response? You replace the JSON, build a new app version, and then test that. It takes a lot of time, right?
Mocking on the backend
The process is almost the same. You create a sample response from the endpoint and hardcode that into the API. On the bright side, your app at least makes a backend request, so the frontend team can at least code the API calls. But the rest of the issues stay the same. And testing different scenarios just take too much effort, deploying a new version for each test.
What can you do differently to avoid these mistakes, you ask? We suggest you use a proxy backend between your app and the backend. Is it more coding? Well, in a way, yes. You need another backend and allocate resources to that, but it can be made pretty reusable. The benefits are that you don't have to touch your frontend or backend code to make changes in the mock data. You simply do that in the mock proxy. You only change the DEV URL in your app, and then every request goes to your proxy, which mocks everything or forwards the request to your backend and its response to the app. This way, you can alter the request the backend receives or the response it sends back.
With a few simple tools and techniques, you can quickly test your code against a real API without having to worry about the negative impacts of actually using it. You'll be able to confidently determine problems and bugs in your code.
What can we do with it?
You can change any parameter of the request and the response entirely or partially.
Of course, it has to be "backward compatible", so we should still be able to fully mock an endpoint. When your backend is not ready, just mock it like it's working. Be that a string or JSON, add any headers and set what you need to to get the response you need for your app.
Change or mock only a part of the data on the request or the response side. For example, add an extra header to the request, like an auth token. Add an icon to every element in the response list.
This is the most remarkable feature. For example, let's say you have a working backend already, but you need to make some changes while the backend team is on holiday. You could mock the whole response, but why waste the existing endpoints? You can make the changes in the proxy to the already existing response and change only one parameter or some.
Do you want to achieve something custom-tailored? Why not write a simple code based on the original request and response parameters? Do whatever you want: call an external API, do a bunch of loops, or even write your AI in there.
Do you like the idea?
We've got some excellent news for you! After struggling with the old-fashioned methods for years, we realized we needed to improve and move to the 2.0 version of mocking. We've just released our solution implementing these cool features. It's called Proxytool, and it's 100% online, so you will be able to mock for your mobile and web apps too. Even your PO will be able to test with mock data. It's an easy-to-use tool that lets you set up your mock environment and responses in five minutes with just a few clicks.
I know what you're thinking: "Five minutes? But that's not enough time to get my cup of coffee!" But here's the thing: if you are mocking the traditional way, you'll have wasted a lot more time.
And if it does work correctly, five minutes is nothing compared to how much faster development will go when you don't have to worry about getting caught up with bugs caused by weird interactions between different parts of the code base.
Logging and extra features
Proxytool also offers you a comprehensive logging solution. You see all the original data and everything you did with it. If your QA engineer breaks the app, you don't have to plug in the phone to read through the logs or fight back and forth with the backend team until someone somehow reproduces it while everyone is watching the logs. Open up the Logs page in your project on Proxytool, and you will find every detail to help your debugging. You can quickly rule out that it was a data issue.
In the future, we plan to develop more and more features to support QA engineers. The first initiative for this is the Rule URL. For each modification rule you create in your project, you can get a specific endpoint to use in your End-to-end tests, for example. You can replace your API URL with the given one, so for each test case, you can specify which Rule to use.