Mockoon

Hello. I would like to talk about the application for organizing a mock server Mockoon. This is a fairly convenient and powerful program, but nothing was found about it in the Russian-speaking segment of the Internet, so I decided to share my experience of using it with examples of features.

I work as a mobile application tester and to test the UI it is often necessary to change the data in order to see the display of elements in different states. For example, the application has a screen with information about the order (comes from a back in JSON format), which displays the number, price, order contents, and some other information. And the number of states for the same field can be different: somewhere there is an order with a promotional code, discount, coupon, somewhere the number of goods is different, the product has been replaced, removed from the order, the field may or may not be present. Or they just added a new field and need to see how it works, but the back is not ready to send us this field yet. In order not to look for a ready order with suitable conditions every time or to do it through the database (sometimes this is not possible), you can change the answer by specifying the desired values.

For such purposes, programs like Charles or Proxyman are usually used.

With such checks, for me, the main inconvenience is the speed of switching between options and the storage of mocks for the answer. When you do not have a large set of data and screens, you can use it, but over time, with an increase in the number of state options, it becomes not very good. Well, using a special application for mocks should be more convenient.

After searching, I settled on the popular Wiremock and the unknown Mockoon.

I looked at Wiremock a little – I didn’t like the controls, I didn’t deal with the settings and switched to Mockoon.

Mockoon is a cross-platform application with a visual interface, free to use, with paid support. There are versions for Windows, Mac, Linux.
With it, you can easily set up a mock server for debugging and testing rest requests. Also here you can store a collection of mocks for different conditions and generate the necessary data. It is possible to raise a customized collection in docker. Plus there is support for trigger rules and data generators.

Interface

Dock with a description from the developers https://mockoon.com/docs/latest/gui-cheat-sheet/

All screenshots were made in the Mac version, in version 1.20, so there may be differences in other platforms.

In the left column there is a list of collections (a set with requests and responses), after installing the program there is already an example with an overview of some of the features.

The following is a list of requests indicating the type of request.

The main part is the request settings area: request type, path, response code, choice of response version (mock) and its settings.

For each mock, you can specify the body, headers, rules for triggering this mock.

Mock can be a separate file (what you wanted to get away from) and part of a collection.

Main cases

Consider an example of compiling a mock for the simplest case.

If so, here the same from developers.

For example, our application makes a GET request to the address https://www.application.com/path/to/profile and we need to change only this request.

Create a new Example collection and switch to it

On the Settings tab, we specify the port on which our collection with mocks will work. The default is 3001.

Next, on the Proxy tab, specify the domain for the request and turn on the Enable proxy mode checkbox – with it, requests will go bypassing Mockoon if there are no suitable responses in the collection, and accordingly they will not be wet.

Switch to the Routes tab. Here we specify the GET request type, the path/to/profile endpoint, and the response body. Leave the response code 200.

Everything is ready, it remains to run and check.

We press the button with the green triangle Start server – the collection has an activity indicator. If you click on the arrow icon to the right of the request address, our mock will open in the browser at the address http://localhost:3001/path/to/profilerespectively, localhost can be changed to the ip of our computer on the network, for example 192.168.1.10 and accessed from the local network, the result will be the same.

http://localhost:3001/path/to/profile
http://localhost:3001/path/to/profile

On the Logs tab, if necessary, you can view detailed information on requests passing through Mockoon.

Now, if you need to see the response in the application, it remains to set up a redirect through our ip and port (for example, to http://192.168.1.10:3001) and execute the request, our mock will open at path/to/profile. At the same time, all other requests will go by as usual.

Redirection can be configured through the same Charles or Proxyman.

The answer can be changed directly in the editor and the changes will be immediately given in the answer, without unnecessary restarts – it is convenient to debug.

Using built-in functions

Now let’s look at a more interesting example, using templates, rules, and data generators, to show some of the program’s capabilities.

For example, the application has a method for getting an order by id (orders/{id}) and we want to see different data depending on the requested order id: for orders/1, the response will be static, and for other id values ​​(for example, orders/2) the data in the response will be generated.

By analogy with the request from the first example, let’s add a new request orders/:id to the collection

Since we have a variable value for id, we will process it through a rule, for this we indicate in the address the parameter by which we will apply the rule, we indicate this parameter through a colon :id (the id name can also be different, set it so that it was understandable).

Available checks for rules
Available checks for rules

To create rules, data is available from the request address, parameters, body, headers, cookies.

On the Rules tab, add the rule itself: if the value in the path for id is = 1, then a response will come from Response 1, which we will write on the Status & Body tab

Now let’s add a response for the value if id is different from 1.

To do this, next to Response 1, click on the plus (Add response) – one more answer option will be added. We will also add a rule in it, but now for id != 1, click on the exclamation mark to invert the rule.

Add new Response 2 with response code 200
Add new Response 2 with response code 200

We will generate data in the response body. Mockoon uses the Faker library and its own helpers to generate data. Let’s write the following example on the Status&Body tab:

"id": {{urlParam 'id'}},
"name": "{{faker 'name.firstName'}}",
"price": {{int 1000 3000}},
"delivery": {{oneOf (array '0' '150' '500')}},
"notiffications": {{boolean}}

For “id” we take the value from the request, which we have designated as :id.

For “name” a name is generated via Faker.

For “price” an arbitrary number is taken from the range from 1000 to 3000.

For the “delivery” parameter, a value is randomly taken from the available ones: 0, 150 or 500.

The “notiffications” parameter has a boolean type, true or false will be generated for it.

A complete list is at documentation page.

Now, if you make a request to /orders/1, then the response will contain a static response from Response 1.

/orders/1
/orders/1

And if the request is, for example, on /orders/23, then the response will be Response 2 and approximately the following values ​​will be generated:

/orders/23
/orders/23

Each request will generate new data.

A couple more moments

Rules can be combined to set the desired conditions. I will not describe this, since there are already many options. For example, if you add a header or specify a parameter in the request body, and change it if necessary, you can get the desired responses along the same request path.

For one endpoint, you can add many response options, with different data, statuses, trigger conditions.

If no rules are set for the mock or there are no suitable rules to trigger, and the endpoint matches, then the version of the mock that is marked as the main one will be returned in the response. This is done by a flag in the drop-down list of answer options.

When parameters are passed in the request, for example cart?update=false&promo=example, then only cart is written to the path and the rest of the values ​​are put into the rules.

Perhaps the application will complain about the lack of an authorization token in the mock response, you can extract it from the request and substitute it in the response. To do this, on the Headers tab, add the Authorization header and the value {{header ‘Authorization’}}

If some query in the collection is not needed, then it can be turned off by selecting Toggle.

After enabling / disabling the request, in order for the changes to work, you need to restart the service with the yellow arrow.

Deploying a service in docker

Let’s say you need to share with someone the necessary mocks for testing on a remote machine. Let’s prepare the collection: if necessary, enable or disable the necessary requests, set the port, specify the address in the proxy where requests will go past the mokun, set up rules for requests, save the collection file on the desired machine. It assumes that docker is already configured.

To create an image on a remote machine, run

sudo docker run -d --mount type=bind,source=/home/user/mocks/Example.json,target=/data,readonly -p 3001:3001 mockoon/cli:latest --data data --port 3001

where source is the address to the file with mocks

port 3001, which was used when setting up in Mockoon and where mocks will be available

The final url for testing will be the address of the machine and the specified port. When accessing, requests go through Mockoon, the mock works if the request matches the rules, and the rest of the requests go by as usual, to the address specified when setting up the collection.

We use stands for testing at work, each developer and tester has his own stand for developing and checking code. Therefore, to check different cases, I simply set up collections with data on the required port and, depending on the task, switched the port for accessing the stand.

Conclusion

By applying the rules, you can set up the display of different cases within the same collection. And if the application is not large, then block all its functionality. Sometimes it happens that the back is lying or partially unavailable, and in order not to wait for repairs, you can continue to work.

The documentation contains a description of building more complex structures, where you can apply conditions, depending on the parameters in the body, headers, request address, extract and use this data to build more complex structures, but I haven’t used them in practice since it’s still redundant for my purposes .

The described functionality is far from complete (plus I did not describe the obvious points), it is based on my experience for application to testing a mobile application.

The entire collection of mocks is stored in one file (by the way, the json format, not some special one) and the request structure is more streamlined (each endpoint has its own set of mocks, there are comments if necessary).

Among the shortcomings: the application is available only in a dark theme (it is not always convenient to work in a dark theme during the day) and, apparently, a white one is not planned yet, according to the comments of the developers. Also, if changes in the collection are made in the new version, then opening in the old one will not work – you will need to update.

Thank you for your attention.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *