{"id":54188,"date":"2019-12-20T00:00:00","date_gmt":"2019-12-19T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/chem-testmace-luchshe-postman"},"modified":"2020-02-18T14:02:10","modified_gmt":"2020-02-18T11:02:10","slug":"chem-testmace-luchshe-postman","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/chem-testmace-luchshe-postman","title":{"rendered":"What Makes TestMace Better than Postman","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"What<\/p>\n

<\/p>\n

Hello everyone, this is TestMace<\/a><\/noindex>! Many might know us from our<\/a><\/noindex> previous<\/a><\/noindex> articles<\/a><\/noindex>For those who have just joined: we are developing an IDE for working with the TestMace API. The most common question when comparing TestMace with competing products is, \"How do you differ from Postman?\" We decided it was time to provide a comprehensive answer to this question. Below, we have outlined our advantages over Postman<\/a><\/noindex>.<\/p>\n

<\/a><\/noindex><\/p>\n

Node separation<\/h2>\n

<\/p>\n

If you work with Postman, you know that the request interface contains all the necessary functionality. It has scripts, tests, and, of course, the requests themselves. While this simplifies work for beginners, this approach is not flexible for larger scenarios. What if you want to create several requests and aggregate them? What if you want to execute a script without making a request or chain several logically separate scripts together? Ultimately, it would be nice to separate tests from regular utility scripts. Additionally, the approach of 'adding all functionality into one node' is not scalable\u2014the interface quickly becomes overloaded.<\/p>\n

<\/p>\n

TestMace initially divides all functionality into different types of nodes. Want to make a request? Here\u2019s your request step<\/a><\/noindex> node. Want to write a script? Here\u2019s your script<\/a><\/noindex> node. Need tests? Here you go \u2013 Assertion<\/a><\/noindex> node. Oh, and you can wrap all of this in a folder<\/a><\/noindex> node. And everything easily combines with each other. This approach is not only very flexible but also, in accordance with the principle of single responsibility, allows you to use only what you really need at the moment. Why do I need scripts and tests if I just want to make a request?<\/p>\n

<\/p>\n

Human-readable project format<\/h2>\n

<\/p>\n

There is a conceptual difference in storage between TestMace and Postman. In Postman, all requests are stored somewhere in local storage. If there is a need to share requests among several users, one must use the built-in synchronization feature. In fact, this is a common approach, but not without its drawbacks. What about data security? After all, some companies' policies may not allow storing data with third parties. However, we believe that TestMace can offer something better! And that improvement is called 'human-readable project format.'<\/p>\n

<\/p>\n

First of all, TestMace has the concept of a 'project'. The application was originally developed with the intent of storing projects in version control systems: the project tree is almost perfectly mirrored in the file structure, it uses YAML as the storage format (without unnecessary brackets and commas), and the file representation of each node is detailed in the documentation with comments. However, in most cases, you won\u2019t need to look there \u2014 all field names have logical titles. <\/p>\n

<\/p>\n

What does this offer the user? It allows for very flexible workflow changes for the team, utilizing familiar approaches. For example, developers can store the project in the same repository as the backend. In branches, in addition to modifying the codebase itself, the developer can also update existing request scenarios and tests. After committing changes to the repository (git, svn, mercurial \u2014 whatever you prefer), the CI (your favorite, non-imposed one) runs our command-line utility testmace-cli<\/a><\/noindex>, and the report generated after execution (for example, in the JUnit format, which is also supported in testmace-cli) is sent to the corresponding system. Moreover, the aforementioned security question is no longer a problem.<\/p>\n

<\/p>\n

As you can see, TestMace does not impose its ecosystem and paradigm. Instead, it easily integrates into already established processes.<\/p>\n

<\/p>\n

Dynamic Variables<\/h2>\n

<\/p>\n

TestMace adheres to the no-code concept: if a problem can be solved without using code, we strive to provide that option. Working with variables is one of those functionalities where in most cases programming can be avoided.<\/p>\n

<\/p>\n

Example: we received a response from the server and we want to save part of the response in a variable. In Postman, we would write something like this in the test script (which is itself strange):<\/p>\n

<\/p>\n

var jsonData = JSON.parse(responseBody);\npostman.setEnvironmentVariable(\"data\", jsonData.data);<\/code><\/pre>\n
<\/p>\n
However, in our opinion, writing a script for such a simple and frequently used scenario seems excessive. Therefore, in TestMace, you can assign a piece of the response to a variable using the graphical interface. Take a look at how simple it is:<\/p>\n
<\/p>\n
\"What<\/p>\n
<\/p>\n
Now, with each request, this dynamic variable will be updated. However, you might argue that the Postman approach is more flexible, allowing not only assignments but also some preprocessing. Here's how you can modify the previous example:<\/p>\n
<\/p>\n
var jsonData = JSON.parse(responseBody);\npostman.setEnvironmentVariable(\"data\", CryptoJS.MD5(jsonData.data));<\/code><\/pre>\n
<\/p>\n
Well, for this, TestMace offers script<\/a><\/noindex> a node that covers this scenario. To replicate the previous case but in TestMace, you need to create a script node after the request and use the following code as the script:<\/p>\n
<\/p>\n
const data = tm.currentNode.prev.response.body.data;\ntm.currentNode.parent.setDynamicVar('data', crypto.MD5(data));<\/code><\/pre>\n
<\/p>\n
As you can see, the composition of nodes has served well here too. And for such a simple case as described above, you can simply assign the expression ${crypto.MD5($response.data)}<\/code> to the variable created through the graphical interface!<\/p>\n
<\/p>\n
Creating tests via GUI<\/h2>\n
<\/p>\n
Postman allows creating tests by writing scripts (in the case of Postman, this is JavaScript). This approach has numerous advantages \u2014 almost unlimited flexibility, availability of ready-made solutions, etc.<\/p>\n
<\/p>\n
However, the reality is often such (it's not us, it's life) that testers do not have programming skills, yet would like to contribute to the team right now. For such cases, following the no-code concept, TestMace allows for creating simple tests via a graphical interface without resorting to scripting. Here's what the process of creating a test that compares values for equality looks like:<\/p>\n
<\/p>\n
\"What<\/p>\n
<\/p>\n
However, creating tests in the graphical editor does not eliminate the ability to write tests in code<\/a><\/noindex>. Here, the same libraries apply as in the script node, and chai<\/a><\/noindex> for writing tests.<\/p>\n
<\/p>\n
Other differences<\/h2>\n
<\/p>\n