Hi all. We are slowly coming out of the shadows and continue a series of articles about our product. After previous review article, we received a lot of feedback (mostly positive), suggestions and bug reports. Today we will show TestMace in action and you will appreciate some of the features of our application. For a more complete immersion, I advise you to refer to our documentation at http://docs-ru.testmace.com. So let's go!

Installation

Let's start with the banality. The application is available and actually tested on three platforms - Linux, Windows, MacOS. You can download the installer for the OS of interest from of our site. For Linux users, it is possible to install package snap. We really hope that hands will soon reach the Microsoft Store and the App Store (Is it necessary? What do you think?).

Experimental script

We chose the following standard scenario as our test case:

log in: user - admin, password - password
add a new entry
check the correct addition of the record

We will test on https://testmace-quick-start.herokuapp.com/. This is the usual json server, perfect for testing such applications. We just added token authorization to all json-server routes and made a login method to get this very token. We will move progressively, gradually improving our project.

Creating a project and trying to create an entity without authorization

Let's start by creating a new projectFillet->New project). If you are running the application for the first time, a new project will open automatically. First, let's try to make a request to create a new record (maybe the creation of records is available without authorization). Select the items in the context menu of the Project node Add node -> RequestStep. Set the node name to create-post. As a result, a new node will be created in the tree and a tab for this node will open. Set the following query parameters:

Request type: POST
url: https://testmace-quick-start.herokuapp.com/posts
Request body: json with value {"title": "New testmace quick start post"}
If you did everything correctly, the interface will look like this:

However, if we try to fulfill the request, the server will return a 401 code, and without authorization, nothing shines on this server. Well, as expected.)

Adding an authorization request

As already mentioned, we have a POST endpoint /login, which accepts a json like this as the request body: {"username": "<username>", "password": "<password>"}Where username и password (again, from the introductory above) have the meanings admin и password respectively. In response, this endpoint returns a json of the form {"token": "<token>"}. Let's use it for authorization. Let's create RequestStep node named login, will act as an ancestor Project node. Drag-and-drop to move the given node higher in the tree than the node create-post. Let's set the following parameters to the newly created request:

Request type: POST
url: https://testmace-quick-start.herokuapp.com/login
Request body: json with value {"username": "admin", "password": "password"}

Let's execute the request and get the XNUMXth code with the token in the response. Something like this:

Refactoring: remove domain duplication

While the requests are not linked into a single script. But this is not the only drawback. If you look closely, you can see that at least the domain is duplicated in both requests. Not good. It's time to refactor this part of the future script, and variables will help us with this.

In a first approximation, variables perform the same role as in other similar tools and programming languages - eliminating duplication, improving readability, etc. You can read more about variables in our documentation. In this case, we need user variables.

Let's define a variable at the Project level of the node domain with the value of https://testmace-quick-start.herokuapp.com. For this, it is necessary

Open the tab with this node and click on the calculator icon in the upper right
Click on + ADD VARIABLE
Enter the name and value of the variable
In our case, the dialog with the added variable will look like this:

OK. Now, due to inheritance, we can use this variable in descendants of any nesting level. In our case, these are nodes login и create-post. In order to use a variable in a text field, you need to write ${<variable_name>}. For example, the login url is converted to ${domain}/login, respectively for create-post node url will look like ${domain}/posts.

Thus, guided by the DRY principle, we have slightly improved the script.

Saving the token to a variable

Since we are talking about variables, let's develop this topic a little. At the moment, in case of a successful login, we receive an authorization token from the server, which we will need in subsequent requests. Let's store this token in a variable. Because the value of the variable will be determined during the execution of the script, we use a special mechanism for this - dynamic variables.

Let's start with a login request. In the tab parsed hover the cursor over the token and select the item Assign to variable. A dialog will appear with the following fields:

Path - what piece of the answer is taken (in our case it is body.token)
current value - what value lies along the path Path (in our case, this is the value of the token)
variable name - the name of the variable, where current value will be saved. In our case it will be token
Node - in which of the ancestors the variable will be created variable name. Select Project

The completed dialog looks like this:

Now every time node is executed login dynamic variable token will be updated with the new value from the response. And this variable will be stored in Project node and, thanks to inheritance, will be available to descendants.

To access dynamic variables, you need to use built-in variable $dynamicVar. For example, to reach the stored token, you need to call ${$dynamicVar.token}.

Throwing an authorization token into requests

In the previous steps, we got an authorization token and all we need to do is add the header Authorization with meaning Bearer <tokenValue> in all requests requiring authorization, including create-post. There are several ways to do this:

Manually copy the token and add the authorization header to the requests of interest. The method is working, but its use is limited only to requests of the “made and thrown away” type. Not suitable for multiple script execution
Take advantage of the functionality authorization.
Use default headers

The use of the second method seems obvious, but in the context of this article, this approach is ... uninteresting. Well, in fact: the authorization mechanism plus or minus is familiar to you from other tools (even if we have things like authorization inheritance) and is unlikely to raise questions.

Another thing is the default headers! In a nutshell, default headers are ancestral HTTP headers that are added to the request by default unless explicitly disabled. Using this functionality, you can, for example, implement custom authorization or simply get rid of duplication in scripts. Let's use this feature to roll the token in the headers.

Previously, we had the foresight to store the token in a dynamic variable $dynamicVar.token at the Project node level. It remains to do the following:

Define default title Authorization with the value of Bearer ${$dynamicVar.token} at the Project node level. To do this, in the Project interface of the node, you need to open a dialog with default titles (button Headers in the upper right corner) and add an appropriate title. The dialog with filled values will look like this:
Disable this header from the login request. This is understandable: at the time of login, we still do not have a token and we will install it with this request. Therefore, in the login request interface, in the tab Headers in Inherited uncheck the Authorization header.

That's all. The Authorization header will now be added to all requests that are children of the Project node, except for the login node. It turns out that at this stage we already have a script ready and we just have to run it. You can run the script by selecting Run in the context menu of the Project node.

Checking the correctness of the post

At this stage, our script can log in and, using an authorization token, create a post. However, we need to make sure that the newly created post has the correct name. That is, in essence, it remains to do the following:

Send a request to get a post by id,
Check that the name received from the server matches the name passed when creating the post

Let's consider the first step. Since the value of id is determined at runtime, we need to create a dynamic variable (let's call it postId) from node create-post at the Project node level. We already know how to do this, just refer to the section Saving the token to a variable. It remains only to create a request to receive a post by this id. To do this, create a RequestStep get-post with the following parameters:

Request type: GET
URL: ${domain}/posts/${$dynamicVar.postId}

To implement the second step, we need to get acquainted with Assertion node. Assertion node is a node that allows you to write checks for certain requests. Each Assertion node can contain multiple assertions (checks). You can read more about all types of assertions from our documentation. We will use Compare assertion with statement equal. There are several ways to create assertions:

Long. Manually from the context menu of the RequestStep node create an Assertion node. In the created Assertion node, add the assertion of interest and fill in the fields.
Fast. Create an Assertion node along with an assertion from the node's RequestStep response using the context menu

Let's use the second method. Here is how it will look for our case.

For those who don't understand, here's what happens:

Make a request to a node get-post
The tab parsed answer call the context menu and select Create assertion -> Compare -> Equal

Congratulations, we've created our first quiz! Simple, isn't it? Now you can run the script completely and enjoy the result. It remains quite a bit to refactor and take out title into a separate variable. But we'll leave that to you as homework)

Conclusion

In this guide, we have created a full-fledged scenario and at the same time reviewed some of the features of our product. Of course, we did not use all the functionality, and in the following articles we will conduct a detailed review of the TestMace capabilities. Stay tuned!

PS For those who are too lazy to reproduce all the steps, we kindly filed repository with the project from the article. You can open it with Fillet -> open project and select the Project folder.

Source: habr.com

testMace. Fast start