Why TestMace is better than Postman

Why TestMace is better than Postman

Hello everyone, in touch TestMace! Perhaps many people know about us from наших предыдущих articles. For those who have just joined: we are developing an IDE to work with the TestMace API. The most frequently asked question when comparing TestMace to competing products is "How are you different from Postman?". We decided that it was time to give a detailed answer to this question. Below we have listed our advantages over Postman.

Node division

If you work with Postman, then you know that the request interface contains all the necessary functionality. Here are scripts, and tests, and, in fact, the requests themselves. This makes things easier for beginners, but for large scenarios, this approach is not flexible. What if you want to create several queries and aggregate them? What if you want to execute a script without a request, or several logically separated scripts in a row? After all, it would be nice to separate tests from regular utility scripts. In addition, the “add all the functionality in one node” approach is not scalable - the interface quickly becomes overloaded.

TestMace initially divides all functionality into different types of nodes. Would you like to make a request? It is for you request step node. Do you want to write a script? It is for you script node. Need tests? Please - Assertion node. Oh yes, you can still wrap the whole thing in folder node. And all this is easily combined with each other. This approach is not only very flexible, but also, in accordance with the principle of unique 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?

Human readable project format

There is a conceptual difference between TestMace and Postman in terms of storage. In Postman, all requests are stored somewhere in local storage. If there is a need to share requests between several users, then you need to use the built-in synchronization. In fact, this is a generally accepted approach, not without flaws. How about data security? After all, the policy of some companies may not allow storing data with third parties. However, we think that TestMace has something better to offer! And the name of this improvement is “human-readable project format”.

Let's start with the fact that in TestMace, in principle, there is a “project” entity. And the application was originally developed with an eye to storing projects in version control systems: the project tree is almost one-to-one projected onto the file structure, yaml is used as the storage format (without extra brackets and commas), and the file representation of each node is described in detail in the documentation with comments . But in most cases, you will not look there - all field names have logical names.

What does this give the user? This allows you to very flexibly change the workflow of the team, using the usual approaches. For example, developers can store the project in the same repository as the backend. In branches, in addition to changing the codebase itself, the developer can fix existing query scripts and tests. After committing changes in the repository (git, svn, mercurial - whatever you like best), CI (your favorite, not imposed by anyone) launches our console utility testmace-cli, and the report received after execution (for example, in the junit format, which is also supported in testmace-cli) is sent to the appropriate system. And the above-mentioned security issue is no longer a problem.

As you can see, TestMace does not impose its own ecosystem and paradigm. Instead, it easily integrates into established processes.

Dynamic variables

TestMace follows the concept of no-code: if a problem can be solved without using code, we try to make it possible. Working with variables is exactly the kind of functionality where in most cases you can do without programming.

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

var jsonData = JSON.parse(responseBody);
postman.setEnvironmentVariable("data", jsonData.data);

But in our opinion, writing a script for such a simple and frequently used script looks redundant. Therefore, in TestMace it is possible to assign a piece of the answer to a variable using a graphical interface. Take a look at how easy it is:

Why TestMace is better than Postman

And now, with each request, this dynamic variable will be updated. But you can object, arguing that the postman approach is more flexible and allows you not only to make an assignment, but also to perform some preprocessing. Here's how you can modify the previous example:

var jsonData = JSON.parse(responseBody);
postman.setEnvironmentVariable("data", CryptoJS.MD5(jsonData.data));

Well, for this, TestMace has script node that covers this scenario. In order to reproduce the previous case, but already executed by TestMace, you need to create a script node after the request and use the following code as a script:

const data = tm.currentNode.prev.response.body.data;
tm.currentNode.parent.setDynamicVar('data', crypto.MD5(data));

As you can see, the composition of the nodes has done a good job here too. And for such a simple case as described above, you can simply assign the expression ${crypto.MD5($response.data)} variable created through the GUI!

Creating Tests Through the GUI

Postman allows you to create tests by writing scripts (in the case of Postman, this is JavaScript). This approach has solid advantages - almost unlimited flexibility, the availability of ready-made solutions, etc.

However, the reality is often such (we are not like that, life is like this) that the tester does not have programming skills, and the team would like to bring benefits right now. For such cases, following the concept of no-code, TestMace allows you to create simple tests through a graphical interface without resorting to writing scripts. For example, here is how the process of creating a test that compares values ​​for equality looks like:

Why TestMace is better than Postman

However, creating tests in a graphical editor does not cancel the possibility writing tests in code. Here are all the same libraries as in the script node, and chai for writing tests.

Often there are situations when a certain query or even an entire script needs to be executed several times in different parts of the project. An example of such requests is custom multi-stage authorization, bringing the environment to the desired state, etc. In general, speaking in terms of programming languages, we would like to have functions that can be reused in different parts of the application. In TestMace, this function is performed by link node. Using it is very simple:
1) create a query or script
2) create a node of type Link
3) in the parameters, specify a link to the script created in the first step

In a more advanced variant, you can specify which dynamic variables from the script to bounce up a level from the reference. Sounds confusing? Let's say we created a Folder with the name create-post, inside which a dynamic variable is assigned to this node postId. Now in the Link node create-post-link you can explicitly tell the variable postId assigned to an ancestor create-post-link. This mechanism (again, in programming language) can be used to return a result from a "function". In general, cool, DRY in full growth and again not a single line of code was affected.

Why TestMace is better than Postman

As for Postman, the feature request for reusing requests hanging since 2015, and it seems there is even some hintsthat they are working on this problem. In its current form, Postman certainly has the ability to change the flow of execution, which in theory probably allows you to implement such behavior, but this is more of a dirty hack than a really working approach.

Other differences

  • Greater control over the scope of variables. The smallest scope within which you can define a variable in Postman is collection. TestMace allows you to define variables for any query or folder. In Postman, Share collection allows you to export only collections, while in TestMace, sharing works for any node
  • TestMace supports inherited headers, which by default can be substituted into child queries. Postman has this a task, and it is even closed, but as a solution it is proposed ... use scripts. In TestMace, this is all configured via the GUI and there is an option to disable inherited headers in specific descendants
  • undo/redo. Works not only when editing nodes, but also when moving, deleting, renaming and other operations that change the structure of the project
  • Files attached to requests become part of the project and are stored with it, while being perfectly synchronized, unlike Postman. (Yes, you no longer need to manually select files each time you start and transfer them to colleagues in archives)

Features that are already on the way

We could not resist the temptation to lift the veil of secrecy over the next releases, especially when the functionality is very tasty and is already undergoing pre-release polishing. So let's meet.

Functions

As you know, Postman uses so-called dynamic variables to generate values. Their list is impressive. and the vast majority of functions serve to generate fake values. For example, to generate a random email, you need to write:

{{$randomEmail}}

However, since these are variables (albeit dynamic ones), they cannot be used as functions: they are not parameterizable, therefore, it will not work to take a hash from a string.

In TestMace, we plan to add "honest" features. Right inside ${} it will be possible not only to refer to a variable, but also to call a function. Those. if we need to generate the notorious fake email, we just write

${faker.internet.email()}

In addition to being a function, you can see that it is possible to call a method on an object. And instead of a big flat list of dynamic variables, we have a set of logically grouped objects.

But what if we want to calculate the hash of a string? Easily!

${crypto.MD5($dynamicVar.data)}

You may notice that you can even pass variables as parameters! At this point, an inquisitive reader may suspect something was wrong ...

Using JavaScript in Expressions

… And for good reason! When the requirements for functions were being formed, we suddenly came to the conclusion that it was necessary to allow valid javascript to be written in expressions. So now you are free to write expressions like:

${1 + '' + crypto.MD5('asdf')}

And all this without scripts right in the input fields!

As for Postman, you can only use variables here, and when you try to write a little bit of an expression, the validator swears and refuses to evaluate it.

Why TestMace is better than Postman

Advanced autocompletion

At the moment, TestMace has a standard autocompletion that looks like this:

Why TestMace is better than Postman

Here, in addition to the auto-completed string, it is indicated what the given string belongs to. This mechanism works only in expressions framed by brackets ${}.

As you can see, visual markers have been added that indicate the type of the variable (for example, string, number, array, etc.). You can also change auto-completion modes (for example, you can choose auto-completion with variables or headers). But even this is not the most important thing!

First, autocomplete works even in expressions (where possible). Here's what it looks like:

Why TestMace is better than Postman

And secondly, auto-completion is now available in scripts. See how it works!

Why TestMace is better than Postman

It makes no sense to compare this functionality with Postman - there autocompletion is limited only to static lists of variables, headers and their values ​​(correct me if I forgot something). Scripts are not auto-completed 🙁

Conclusion

October marked the one year anniversary of our product development. During this time, we managed to do a lot of things and in some respects caught up with our competitors. But be that as it may, our goal is to make a really convenient tool for working with the API. We still have a lot of work to do, here is a rough plan for the development of our project for the next year: https://testmace.com/roadmap.

Your feedback will allow us to better navigate the abundance of features, and your support gives us strength and confidence that we are doing the right thing. It so happened that today is an important day for our project - the day of the publication of TestMace on Product Hunt. Please support our project, it is very important for us. Especially since there is a tempting offer on our PH page today, and it is limited

Source: habr.com

Add a comment