Creating Mocks with Postman
Testing an API is important, but you can’t always rely on having access to a working version of the API you need to test. Often, these different parts of a system are developed at slightly different times, so you might be working on a UI element that needs certain data through the API before that data is ready. In that case, you can still test your API by using mock or fake data.
Let’s explore how to create a mock using Postman.
Postman Tutorial Chapters
What is Mock Data?
Mock data is essentially hard coded data that will be returned when a certain endpoint is called with given parameters. It will generally be less complete than the real system, but it has some flexibility advantages. You can, for example, setup your mock data to return errors or create corner cases that might be hard to replicate otherwise. The ability to generate this kind of data is a great tool for a tester to have. As we would expect, creating data like this in Postman is very easy.
Let’s take a look at the jsonplaceholder API again. We already have a request that gets us the data for a given post ID, so let’s take a look at how we could mock that endpoint. Click on the view more actions menu, and choose the Mock Collection option. This will prompt you to create a mock server. A mock server is needed to process and respond to the requests that you will make and to send back the correct mock data. Give the mock server a name and click on the Create Mock Server button. This creates a simple server that you have access to. You can copy the Mock URL, but at this point it won’t do much since you have not put any mock data into the server yet.
Create Mock Examples
In Postman you add mock data to a mock server using examples. In order to do that, go to the jsonplaceholder request that you created earlier in this tutorial and click on the examples button at the top right of the tab.
Click on the Add an Example button and then give your example a name. If you still have the post_id variable in your call you will need to remove it and replace it with an actual post ID like 1. This is so that the mock server is able to resolve the request that you send.
Now you need to setup the example response. This response is the mock data. You can put whatever you want in here as your response. Just to see that it works, let’s type It works! in the body field of the example response. Let’s assume for now that we want to have this as a successful call, so put 200 OK in the Status field Save the example with the Save Example button.
You now have a mock server and an example with mock data that the server can access. The next step is to make a call to the mock server.
Using a Postman Mock Server
Calling a mock server is as simple as replacing the server URL with the mock server URL. In this case, the server URL is https://jsonplaceholder.typicode.com and so everything after that (/posts/1) is the resource path. You need to replace the server URL with your mock server URL. If you need to find the mock server URL, you can click on the arrow beside your collection and go to the Mocks tab to see the current Mock server URL.
If you use that server URL and add the resource endpoint you should end up with a URL that looks something like this:
You can paste that URL into the address bar of your browser and you should see a response that says “It Works!“
From here you can modify the example to respond with other status codes or other data in the body. You can set up the example to respond with different header types as well. In addition, you can create more examples that respond with different kinds of data so that you could do the testing or design that you wanted to.
Conclusion
This tutorial has taken you through all of the greatest benefits of API testing with Postman. If you want to continue to learn more about how to use Postman for API testing, I would encourage you to get hands on experience. Start using Postman to explore APIs of the application you are currently testing. See if you can automate some tests. Set Newman up and try it locally. Try to get Newman to run a couple of tests in your CI system. Create a mock server and use that to test the UI. Make sure to successfully complete all of the steps that we have gone over in this tutorial and when you get stuck on something, check the Postman documentation, search google, look on StackOverflow and ask for help.
It might feel a bit overwhelming at first, but if you stick with it, you will be automating your API testing using Postman before you know it 🚀
Already started your hands on experience with Postman – Share it in the comments below! 👇
About the author
Dave Westerveld is an experienced tester who has been involved in various aspects of the testing role. As a strong exploratory tester, he has learned how to leverage many different tools to enhance his testing powers. He has also been involved in many automation projects including building out new automation frameworks. In addition he has helped transition several large and expensive automation suites into lighter weight, higher value systems. A speaker at several conferences, Dave also blogs about his thoughts and experiences at offbeattesting.com
Join TestProject Community
Don’t forget to share this post
Comments
For post request, when we create example in postman – Headers will not be captured in examples?
Mocking with examples
Mock servers simulate an API by returning predefined data, enabling you to develop or test against an API before it’s production-ready (or without using production data). In Postman, mock servers rely on examples saved in a collection to return mock data. Follow the steps below to get a hands-on demonstration of how mock servers and examples work together, and to learn how you can integrate them into your API workflow.
Creating a mock server
The steps below walk you through the process of creating a mock server in Postman. First, you’ll set up some basics that are required for mock servers to work. Once your mock server is up and running, you’ll send requests to it and see how your examples are used to return data.
This request calls the Postman Echo service which you can use to test REST or SOAP clients and make sample API calls. The resulting response displays in the response pane below the request.
Select Save to save the request in a collection. Collections are groups of requests that you can use to organize your work and create API workflows.
Select New Collection at the bottom of the Save Request dialog box. Enter C1 for the collection name and select Create. Then select Save to save the request to the new collection.
To save the response you received from the Postman Echo service, select Save Response > Save as example. The example is saved underneath the request, inside the C1 collection.
Select Collections in the left sidebar, expand the C1 collection and the request, and then select the example to open it.
When you’re done configuring the mock server, select Create Mock Server. You can access the mock server at any time by selecting Mock Servers in the left sidebar.
First, copy the mock server URL. Select Mock Servers in the left sidebar, select the M1 mock server, and then select Copy Mock URL.
Next, create a new request by selecting + or by selecting New > HTTP Request. Paste the mock URL into the new request and select Send.
Sending a GET request to https://postman-echo.com/test returns a 404 error, which you saved as another example. The collection C1 now has two requests and two saved examples:
Finally, repeat step 5 above, but this time add the path /test to the end of the mock server URL when sending the request. This returns the expected 404 response.
Generating random data with dynamic variables
As you’ve seen in this demonstration, you define the data to be returned by the mock server in your examples. However, there may be cases when you want the mock server to return a response containing random data.
To have your mock server return random data, use dynamic variables in your example’s response body. Dynamic variables are resolved as part of the mock server response and replaced with random data. Dynamic variables are useful for generating random data when mocking an API, and you can use them for exploratory testing and writing rich, data-driven tests.
For instance, your example’s response body might contain dynamic variables as follows:
When you call the mock server endpoint, you’ll see the response data change to something like:
See Dynamic Variables for a full list of dynamic variables for generating random data.
Using query parameters
Postman’s mock service uses a matching algorithm to select the most appropriate saved example to return in response to a request. As part of this algorithm, the mock server looks at the query parameters when matching requests to saved examples. If you have examples that differ only in their query parameters, you can mock different responses for different query parameters on the same request path. In this case, the mock server will return the exact response matching that request path and the corresponding query parameters.
Here’s a scenario that illustrates how matching query parameters works:
The collection Query Params Demo has one request Request1 with two examples, Example1 and Example2.
In Example1, the parameter id has a value of 1 :
In Example2, the parameter id has a value of 5 :
In this scenario, Example1 and Example2 are passing 1 and 5 respectively. When you send a request to the mock server URL and pass these different query parameters, Postman returns the exact response that matches both the path and the passed parameters.
If no exact match is found, Postman returns the best response based on its matching algorithm.
Mocking GraphQL queries
Postman’s mock service enables you to mock GraphQL queries. To mock GraphQL queries, make a request to the mock server using the request path and request body saved in the examples in the mocked collection.
Make sure to set the Content-type header to application/json in your examples.
Also make sure to pass the x-mock-match-request-body header with a value of true when sending a request to the mock server URL.
Postman Mock Server
Mock Server in POSTMAN
A Mock Server is a virtual server that can be your own computer or any software which can be used to act like a real server. A Mock server is used during different API testing when various responses have to be received which are not readily available on the web servers or for some testing that cannot be performed on real servers for security issues.
POSTMAN provides a great facility letting you create a Mock Server inside it.
Creating the MOCK Server in POSTMAN
For creating Mock Server in POSTMAN, you don’t really need any external extensions or applications, but the Mock server is inbuilt in POSTMAN. Let us see how to use it.
Go to the New button in POSTMAN and you will see the option for Mock Server.
Select the Mock Server.
As can you see in the above image, the first column is for the method type. (We selected GET ). In the next column, the Request Path has to be inserted. (<
We can write the response text as plain or HTML document, JSON document, etc.
Now hit the Next button.
Then click into the Create Mock Server, and your Mock server is created.
Now, on the left side of the POSTMAN interface, your Mock Collection should be displayed along with all other existing collections.
As shown in the above request, you can see that a request has been automatically created by POSTMAN for making requests into the Mock server.
Now, open the request and click the send button to send the request.
Now, go the Response Section, and you must be able to see the custom response that you created at the time of creating the Mock Server.
Creating a JSON Response in the Mock Server
So far we have only seen how to create a response in the Mock server and how a request can be made to get the response. Now, we shall see how to create a JSON response and how a request can be made to get the response from the Mock Server.
Let us create a JSON response into the Mock Server. To edit the response, just open the request and then go to the Example in the top right corner of the POSTMAN page.
As you click Examples, you will get a drop-down option called Default. Click into that option and you will be able to edit your response.
As you click into Default option, you will get an area to edit your response. Click into the drop-down menu right to the Preview section in the body section and then select JSON(you can select anyone, but now we are concerned about creating JSON response, so we shall choose JSON response).
After selecting the JSON file, in the body section, write your JSON Response.
Now, hit the save example button and then click to return back.
In the image, the left side button demo, you can return back to the request.
Now, send the request. And wait for some time. Even though the response is made from your local machine through POSTMAN itself, it will take some time to process the request and the response.
Response from Mock Server :
Performing Assertion into Mock Server’s Response
As we saw earlier, in the Assertion Chapter, that assertions are nothing but writing test code. The POSTMAN inbuilt code snippets can be used the javascript code can be customized for making different assertions on the Mock Server’s Response.
Performing Assertions on the Mock Server’s Response is similar to the assertions we make on the Response that we obtain from a distant or remote server(what we call a real server).
Checking the HTTP status code
Go to the Test Tab of the Request and edit the code below:
Click the send button to send the request again and after the response is received, to the Result tab in the Response section and see the result.
Accessing data from the JSON Response
Any data values from the JSON Response can be obtained by accessing the JSON path for that variable. For example, consider the response below.
Edit the following code into the Test tab editor:
Now, click the send button to send the request and after the response is received, see the Result.
Now, send the request and see the Result:
Advanced assertions on the response of a Mock server
Advanced assertions can also be performed on the response from the Mock server. We have already see what are the different types of programming concepts that can be applied to creating assertions. Some of them were conditional statements, some were loops and switch statements.
Assertion using Conditional Statement:
Generally, the conditional statement is a if. When a condition is satisfied or is found to be true, then the if statement gets executed. In this example, we shall that how can we check the existence of a name inside the response. This can be checked by comparing the JSON path of the data with the value we want to check.
In the above example, the line if(mydata == «Rahul») checks the condition for the presence of the name Rahul in the given path.
Console Output :
Checking for data in two different path
It may be possible, that a data value if not found in one path, then can be found in a different path of the JSON response. To check a value in two different places, either we can use two of the statements or can use an OR operator inside the if statement.
Let us check for the name Rahul in one path and the id =1 in a different path. If anyone (name or the id) is matched, then At least one condition is satisfied will be printed in the console, otherwise, None of the condition is satisfied will be printed in the console.
Now, edit the following code into the Tests Tab of the request:
Now, send the request and after the response is received, see the console output:
Using code snippets on Mock server response
As discussed earlier, code snippets are nothing but ready-made codes that are integrated into POSTMAN to create assertions, check status code, search for a keyword, setting or getting variables.
Code snippets help in creating scripts easily and also the time to write code for a simple test can be reduced significantly. Let us see the applications of some code snippets.
To go to POSTMAN snippets, go to the right side of the interface and select the code snippet you want and it will be automatically pasted into the editor.
Some of the snippets which are used in Pre-Test scripts are setting variables, getting variables, etc. On the other hand, some of the snippets which are used in the Tests(which gets executed after the response are received) are: checking status code, performing assertions, implementing other filters, etc.
Checking the status code:
To check the status code, Select Tests Tab of the request, and once the editor is opened, the snippets must be visible to you.
Now, send the request and wait for the response. Once the response is received, go to the Result tab of the Response and see the result:
Searching for a string in the body
Now, send the request and check the result after the response is received.
Matching Status Code
When a response is received, there can be different status codes associated with the response. For example, when a response is received from the server without any interruption or without any error, the status code turns out to be 200.(which means OK).
Now, it is also possible that the server returns some different codes like 201, 202, etc, which are somewhat similar to the Ok status code: 200. Now, let us see how we can check for different status code:
In this example, I shall check for the status code: 200, 201, 202.
Edit the following code into the Tests tab of the request :
In the above code, we have checked for the code- 201, 202, and 200 using the statement:
Now, send the request and see the result tab after the response is received from the server:
As you can see in the above response, it’s showing PASS.
Check for the Response Time
Response time is the time taken by the server to send the response. All the time the server will not be able to send the response with similar efficiency or speed. And the response time decides how good the website is.
Use the code snippets to see the response time or edit the code below:
As shown in the above code, we are checking for the response time to be less than 200 mili-seconds. After it is done, send the request and wait for the response. If the response from the server, has any of the three status codes, the test will PASS.
Введение в Postman
“Разработка API сложна, Postman делает её лёгкой” © Postdot Technologies, Inc
Когда видишь описание инструментов Postman — захватывает дух, просыпается чувство всевластия над своим будущим детищем. Кажется, что и взрощенные в прошлом «монстры» наконец-то падут перед тобой!
В этой статье мы расскажем о Postman и попробуем написать свой первый скрипт.
Postman
Основное предназначение приложения — создание коллекций с запросами к вашему API. Любой разработчик или тестировщик, открыв коллекцию, сможет с лёгкостью разобраться в работе вашего сервиса. Ко всему прочему, Postman позволяет проектировать дизайн API и создавать на его основе Mock-сервер. Вашим разработчикам больше нет необходимости тратить время на создание «заглушек». Реализацию сервера и клиента можно запустить одновременно. Тестировщики могут писать тесты и производить автоматизированное тестирование прямо из Postman. А инструменты для автоматического документирования по описаниям из ваших коллекций сэкономят время на ещё одну «полезную фичу». Есть кое-что и для администраторов — авторы предусмотрели возможность создания коллекций для мониторинга сервисов.
Введение
1 — коллекция, 2 — папка, 3 — запрос
Главные понятия, которыми оперирует Postman это Collection (коллекция) на верхнем уровне, и Request (запрос) на нижнем. Вся работа начинается с коллекции и сводится к описанию вашего API с помощью запросов. Давайте рассмотрим подробнее всё по порядку.
Collection
Коллекция — отправная точка для нового API. Можно рассматривать коллекцию, как файл проекта. Коллекция объединяет в себе все связанные запросы. Обычно API описывается в одной коллекции, но если вы желаете, то нет никаких ограничений сделать по-другому. Коллекция может иметь свои скрипты и переменные, которые мы рассмотрим позже.
Folder
Папка — используется для объединения запросов в одну группу внутри коллекции. К примеру, вы можете создать папку для первой версии своего API — «v1», а внутри сгруппировать запросы по смыслу выполняемых действий — «Order & Checkout», «User profile» и т. п. Всё ограничивается лишь вашей фантазией и потребностями. Папка, как и коллекция может иметь свои скрипты, но не переменные.
Request
Запрос — основная составляющая коллекции, то ради чего все и затевалось. Запрос создается в конструкторе. Конструктор запросов это главное пространство, с которым вам придётся работать. Postman умеет выполнять запросы с помощью всех стандартных HTTP методов, все параметры запроса под вашим контролем. Вы с лёгкостью можете поменять или добавить необходимые вам заголовки, cookie, и тело запроса. У запроса есть свои скрипты. Обратите внимание на вкладки «Pre-request Script» и «Tests» среди параметров запроса. Они позволяют добавить скрипты перед выполнением запроса и после. Именно эти две возможности делают Postman мощным инструментом помогающим при разработке и тестировании.
1 — вкладки с запросами, 2 — URL и метод, 3 — параметры запроса, 4 — параметры ответа
Скрипты
«Postman Sandbox» это среда исполнения JavaScript доступная при написании «Pre-request Script» и «Tests» скриптов. «Pre-request Script» используется для проведения необходимых операций перед запросом, например, можно сделать запрос к другой системе и использовать результат его выполнения в основном запросе. «Tests» используется для написания тестов, проверки результатов, и при необходимости их сохранения в переменные.
Последовательность выполнения запроса (из оф. документации)
Помимо скриптов на уровне запроса, мы можем создавать скрипты на уровне папки, и, даже, на уровне коллекции. Они называются также — «Pre-request Script» и «Tests», но их отличие в том, что они будут выполняться перед каждым и после каждого запроса в папке, или, как вы могли догадаться, во всей коллекции.
Последовательность выполнения запроса со скриптами папок и коллекций (из оф. документации)
Переменные
Postman имеет несколько пространств и областей видимости для переменных:
Глобальные переменные и переменные окружения можно создать, если нажать на шестеренку в правом верхнем углу программы. Они существуют отдельно от коллекций. Переменные уровня коллекции создаются непосредственно при редактировании параметров коллекции, а локальные переменные из выполняемых скриптов. Также существуют переменные уровня данных, но они доступны только из Runner, о котором мы поговорим позже.
Приоритет пространств переменных (из оф. документации)
Особенностью переменных в Postman является то, что вы можете вставлять их в конструкторе запроса, в URL, в POST параметры, в Cookie, всюду, используя фигурные скобки в качестве плейсхолдера для подстановки.
<
Из скриптов переменные тоже доступны, но получить их поможет вызов стандартного метода встроенной библиотеки pm:
Collection Runner
Предназначен для тестирования и выполнения всех запросов из коллекции или папки, на ваш выбор. При запуске можно указать количество итераций, сколько раз будет запущена папка или коллекция, окружение, а также дополнительный файл с переменными. Стоит упомянуть, что запросы выполняются последовательно, согласно расположению в коллекции и папках. Порядок выполнения можно изменить используя встроенную команду:
После выполнения всех запросов формируется отчет, который покажет количество успешных и провальных проверок из скриптов «Tests».
Collection Runner
Console
Пользуйтесь консолью для отладки ваших скриптов, и просмотра дополнительной информации по запросам. Консоль работает, как во время запуска одного запроса, так и во время запуска пакета запросов через Runner. Чтобы её открыть, найдите иконку консоли в нижнем левом углу основного экрана приложения:
Практика
Так как создание коллекций и запросов в конструкторе не должно вызвать затруднений, практическую часть посвятим написанию скриптов, и рассмотрим как создать цепочку запросов с тестами. Перед началом создайте новую коллекцию, назовите её “Habra”, затем создайте новое окружение под названием «Habra.Env»
Шаг 1
Создайте новый запрос, в качестве URL укажите https://postman-echo.com/get?userId=777, а метод оставьте GET. Здесь и далее для простоты и удобства мы будем использовать echo-сервер любезно предоставленный разработчиками Postman. Сохраните запрос в коллекцию «Habra» и назовите “Get user id”, он будет имитировать получение идентификатора пользователя от сервера. Перейдите на вкладку «Tests» и напишите следующий код:
С помощью этого скрипта мы проверили статус и формат ответа, а также сохранили полученный из ответа идентификатор пользователя в переменную окружения для последующего использования в других запросах. Чтобы проверить работу нашего теста, запустите запрос. В панели информации об ответе, во вкладке «Tests» вы должны увидеть зелёный лейбл “PASS”, а рядом надпись “Status is ok, response is json”.
Шаг 2
Теперь давайте попробуем вставить идентификатор нашего пользователя в json запрос. Создайте новый запрос, в качестве URL укажите https://postman-echo.com/post, выберите метод POST, установите тип для тела запроса raw — application/json, а в само тело вставьте:
Сохраните запрос в нашу коллекцию, и назовите «Update username», он будет запрашивать импровизированную конечную точку для обновления username пользователя. Теперь при вызове запроса вместо <
В нашем новом тесте мы сравниваем полученный от сервера userId с тем, что хранится у нас в переменной окружения, они должны совпадать. Запустите запрос и убедитесь, что тесты прошли. Хорошо, двигаемся дальше.
Шаг 3
Вы могли заметить, что два тестовых скрипта имеют одинаковую проверку формата и статуса:
Пока мы не зашли слишком далеко, давайте исправим эту ситуацию и перенесем эти тесты на уровень коллекции. Откройте редактирование нашей коллекции, и перенесите проверку формата и статуса во вкладку «Tests», а из запросов их можно удалить. Теперь эти проверки будут автоматически вызываться перед скриптами «Tests» для каждого запроса в коллекции. Таким образом мы избавились от копирования данной проверки в каждый запрос.
Шаг 4
Мы научились записывать и получать переменные окружения, настало время перейти к чему-то потяжелее. Давайте воспользуемся встроенной библиотекой tv4 (TinyValidator) и попробуем проверить правильность схемы json объекта. Создайте новый запрос, в качестве URL используйте https://postman-echo.com/post, установите метод в значение POST, для тела запроса укажите raw — application/json, и вставьте в него:
После запуска запроса echo-сервер должен вернуть нам нашу json модель в качестве ответа в поле «data», таким образом мы имитируем работу реального сервера, который мог бы прислать нам информацию о профиле Боба. Модель готова, напишем тест, проверяющий правильность схемы:
Готово, мы провалидировали схему объекта profile. Запустите запрос и убедитесь, что тесты проходят.
Шаг 5
У нас получился небольшой путь из 3-х запросов и нескольких тестов. Настало время полностью его протестировать. Но перед этим, давайте внесем небольшую модификацию в наш первый запрос: замените значение “777” в URL на плейсхолдер “<
Теперь запустим Runner. В качестве «Collection Folder» выберем «Habra». В качестве «Environment» поставим «Habra.Env». Количество итераций оставляем 0, а в поле «Data» выбираем наш файл users.json. По этому файлу «Collection Runner» поймет, что ему нужно совершить 4 итерации, и в каждой итерации он заменит значение переменной «newUserId» значением из массива в файле. Если указать количество итераций больше, чем количество элементов в массиве, то все последующие итерации будут происходить с последним значением из массива данных. В нашем случае после 4 итерации значение «newUserId» всегда будет равно 50000. Наш “Data” файл поможет пройти весь наш путь с разными newUserId, и убедиться, что независимо от пользователя все выполняется стабильно.
Запускаем наши тесты нажатием «Run Habra». Поздравляем вы успешно создали коллекцию и протестировали наш импровизированный путь с помощью автотестов!
Тестирование коллекции «Habra»
Теперь вы знаете, как создавать скрипты и вполне можете написать парочку тестов для своего проекта.
Отдельно хочу отметить, что в реальном проекте мы не держим все запросы в корне коллекции, а стараемся раскладывать их по папкам. Например, в папке «Requests» мы складываем все возможные запросы описывающие наш API, а тесты храним в отдельной папке «Tests». И когда нам нужно протестировать проект, в «Runner» запускаем только папочку «Tests».
Полезно знать
В завершении приведем основные команды, которые вам могут понадобиться во время написания скриптов. Для лучшего усвоения, попробуйте поиграться с ними самостоятельно.
Установка и получение переменных
Тестирование или asserts
Создание запросов
Получение ответа для основного запроса
Ответ доступен только во вкладке “Tests”
Работа со встроенными библиотеками
Документация регламентирует наличие некоторого количества встроенных библиотек, среди которых — tv4 для валидации json, xml2js конвертер xml в json, crypto-js для работы с шифрованием, atob, btoa и др.
Некоторые из библиотек, например, как tv4 не требуют прямого подключения через require и доступны по имени сразу.
Получение информации о текущем скрипте
Управление последовательностью запросов из скрипта
Стоит отметить, что данный метод работает только в режиме запуска всех скриптов.
После перехода на следующий запрос Postman возвращается к линейному последовательному выполнению запросов.
Создание глобального хелпера
В некоторых случаях вам захочется создать функции, которые должны быть доступны во всех запросах. Для этого в первом запросе в секции “Pre-request Script” напишите следующий код:
А в последующих скриптах пользуемся им так:
Это лишь небольшой список полезных команд. Возможности скриптов гораздо шире, чем можно осветить в одной статье. В Postman есть хорошие «Templates», которые можно найти при создании новой коллекции. Не стесняйтесь подглядывать и изучать их реализацию. А официальная документация содержит ответы на большинство вопросов.
Заключение
Основные плюсы, которые подтолкнули нас к использованию Postman в своём проекте:
Среди минусов можно выделить:
У каждого проекта свои подходы и взгляды на тестирование и разработку. Мы увидели для себя больше плюсов, чем минусов, и поэтому решили использовать этот мощный инструмент, как для тестирования, так и для описания запросов к API нашего проекта. И по своему опыту можем сказать, даже, если вы не будете использовать средства тестирования, которые предоставляет Postman, то иметь описание запросов в виде коллекции будет весьма полезно. Коллекции Postman это живая, интерактивная документация к вашему API, которая сэкономит множество времени, и в разы ускорит разработку, отладку и тестирование!
P.S.:
Основной функционал Postman бесплатен и удовлетворяет ежедневным нуждам, но есть некоторые инструменты с рядом ограничений в бесплатной версии:
