Hello there! We're coming out of the shadows and continuing the series of articles about our product. We've got so many feedbacks (mainly positive), suggestions, and bug reports after publishing our overview article. Today you'll see in action and try out some features of our application. last TestMace For more information be sure to look over its documentation - . Let's go! http://docs.testmace.com Installation We'll start with some basic things. Our application is available and is being tested on three platforms: Linux, Windows, MacOS. You can download an installer for particular OS from . our site Linuxoids can install a . snap package We're really hoping to get our hands on Microsoft Store and App Store (should we?). Experimental Scenario For our little experiment we have the following standard scenario: log in: user - , password - ; admin password add a new record; check if the record was added correctly. We'll be using the url. It's a plain , perfectly suitable for testing this kind of applications. All we've done is token authorization for all json server routes and the login method for getting this very token. https://testmace-quick-start.herokuapp.com/ json server We'll move step by step, improving our project. Creating a project and trying to create an entity without authorization Let's start with creating a new ( ). If TestMace is launched the first time, it'll be done automatically. Let's issue a request for creating a new post (in case if it is possible without authorization). In the Project node context menu select . project File->New project Add node -> RequestStep Name it . You'll see a new node in the project tree and it's tab will be shown. create-post Set the following request parameters: Request type: POST url: https://testmace-quick-start.herokuapp.com/posts Request body: with the value. json {"title": "New testmace quick start post"} If you do it right, you'll see the following interface: However, if you send this request, the server will return the 401 code, and you won't be able to do anything with the server without authorization. Just as expected. Adding an authorization request As mentioned before, we've got a POST endpoint , that takes the following json as the request body: , where and have the and values respectively. This endpoint returns the following json as a response: . /login {"username": "<username>", "password": "<password>"} username password admin password {"token": "<token>"} Let's use it for authorization. Create a node named with the Project node being its parent. Drag and drop this node above the node in the tree. RequestStep login create-post Set the following parameters for the newly added node: Request type: POST url: https://testmace-quick-start.herokuapp.com/login Request body: with the value. json {"username": "admin", "password": "password"} If you send the request, you'll get the 200 code with the token as a response: Refactoring: removing domain duplication Our requests are not grouped in one scenario yet. But that is not the only problem here. If you look at them closer, you'll see that the domain is duplicated in both requests. That's not good. It's time to refactor this part of our future scenario with the help of variables. Variables in TestMace roughly do all the same things as in other similar tools and languages - deduplication, improving readability, etc. Refer to to read more about variables. This time we'll need user-defined variables. our documentation Define the variable with the value at the Project node level. To do that, you need to: domain https://testmace-quick-start.herokuapp.com Open the Project node tab and click on the calculator icon at the top right of the window; Select ; +ADD VARIABLE Enter the name and value for this variable. In our case, the variable dialog will look like this: OK. Now we can inherit this variable in children of any nesting level and in the and nodes in particular. To use the variable in the text box, you should write . For example, the url for will be written as , and the url for the node - . login create-post ${<variable_name>} login ${domain}/login create-post ${domain}/posts By doing so, we've followed the DRY principle and improved our little scenario. Storing the token in a variable While we're on the subject of variables, let's go a bit further. If the login is successful, we get an authorization token from the server, that we're going to need in future requests. Let's save this token into a variable. Since the variable value is defined while running a scenario, we'll use a special mechanism called . dynamic variables First, let's send the login request. In the tab of the response point to the token in the context menu and select . Parsed Assign to variable You'll see a dialog with the following fields: - the part of a request taken (body.token in our case); Path - the value at the specified path (the token value); Current value — the name of the variable where our will be stored. ( in our case). Variable name Current value token — the parent node where the will be created. Choose . Node Variable name Project The dialog with complete fields should be the following: At this point, every time the node runs, the variable is updated with the value from the response. This variable will be stored in the node and will be available in child nodes, thanks to inheritance mechanism. login token Project To access dynamic variables, use the . For instance, to get to the saved token you should write . default variable $dynamicVar ${$dynamicVar.token} Passing the authorization token into requests Previously we've received an authorization token and now we only need to add the header with the value to every request where authorization is needed, including the request. Authorization Bearer <tokenValue> create-post There are a few ways to do that: To copy the token and add the authorization header to every request manually. This works just fine, but is limited to fire-and-forget requests and not suitable for scenarios; To use feature. authorization To use . default headers The second approach seems to be just what we need, but in terms of this article it's of no interest. Seriously, you should be more or less familiar with the authorization mechanism from other tools and shouldn't have any trouble with it (even though we have such things as in TestMace). authorization inheritance Using default headers is much more exotic. Long story short, default headers are inherited HTTP headers that are by default added to requests if you don't turn it off explicitly. With the help of this feature you can, for example, implement custom authorization or get rid of duplications in your scenarios. Let's use this feature to pass the token through the headers. Earlier we've saved the token into the dynamic variable at the node level. Now we have to: $dynamicVar.token Project 1. Define the default header with the value at the node level. To do that, open the default headers dialog (select the button at the top right of the screen) and add the corresponding header. This is how the dialog with the filled fields should look like: Authorization Bearer ${$dynamicVar.token} Project Headers 2. Disable this header in the request. Sure thing: at the moment of logging in we don't have a token, we'll set it with this particular request. Thus, uncheck the checkbox in the tab in the area. login Authorization Headers Inherited That's it. The authorization header will now be added to all node children, except for the node. Seems, the scenario is ready, and we only need to run it. To do that, select in the node context menu. Project login Run Project Checking if the post was made correctly So far, our scenario can log in and create a post using an authorization token. But we have to make sure that the created post has the correct name. So here's what we need to do: Send a request to get the post via its id; Check if the name received from the server corresponds to the name used while creating the post. Let's discuss the first step. Since the id value is defined while running the script, we need to create a dynamic variable (let's name it ) in the node at the node level. postID create-post Project You already know how to to that, just go to the section. All we have left is sending a request for getting the post by its id. Storing the token in a variable Create a node named with the following parameters: RequestStep get-post Request type: GET URL: ${domain}/posts/${$dynamicVar.postId} To go further, you need to take a closer look at nodes. An Assertion node is a node that allows to create tests for specific requests. Each Assertion node may contain several assertions (tests). To learn more about supported assertions you can refer to our . We'll use a assertion with the operator. Assertion documentation Compare equal There are two ways of creation assertions: Long. Do it manually from the RequestStep node context menu. In the created Assertion node add the desired assertion and fill in the fields. Quick. Create an Assertion node along with the desired assertion from the RequestStep node response using the context menu. Let's stick with the second one. Here's how it'll look like for our example: Basically, you do the following: Create a request in the node. get-post Open the context menu in the tab and select . Parsed Create assertion -> Compare -> Equal Wow, we've just created our first test! Simple as that! Now you can run the full scenario and enjoy the result. You can make it even more beautiful if you put into a separate variable though. title We leave it to you as an exercise :) Conclusion In this guide we created a full-blown scenario and tried some features of our product as well. Of course, these were just a few of them, and we're going to make a full review of all TestMace features next time. So watch out for updates in our blog! P.S. If you feel lazy to follow the steps described in the article, we've have a with this project just for you. Select and choose the folder. repository File -> Open project Project
