Why TestMace is better than Postman
Tags: showdev, webdev, startup, productivity
Published: 2019-12-18 11:03:07

Hello, this is [Testmace](http://testmace.com)! You might have known about us from [our](https://dev.to/dimansny/getting-started-with-api-testing-by-using-testmace-3no) [previous](https://dev.to/dimansny/we-built-an-ide-to-work-with-api-design-here-s-what-we-did-5dhe) [articles](https://dev.to/dimansny/why-testmace-has-chosen-electron-p0k). For those who have just joined us: we're working on Testmace - an IDE for API design. How are you different from [Postman](https://www.getpostman.com/)? This is the most frequently asked question while comparing TestMace to other similar products. It feels like the time we gave a detailed answer to it. You can see all benefits of our product down below.

# Nodes

If you use Postman, you must be aware that the interface of a request has all necessary features. You can see scripts, tests, and requests there. It makes things easier for new users, but in more complex scenarios this approach isn't flexible enough. What if you need to create a few requests and aggregate them? What if you want to run a script without creating a request or multiple logically separated scripts? At least you would definitely like to separate tests from basic utility scripts. Moreover, the all-features-in-one-node approach is unscalable since the interface quickly becomes too heavy.

TestMace initially separates features among nodes of different type. You want to send a request? A [request step](https://docs.testmace.com/node-types/request-step) node is here for you. You'd like to write a script? Use a [script](https://docs.testmace.com/node-types/script) node for that. Need tests? An [assertion](https://docs.testmace.com/node-types/assertion-node) node, here you go. By the way, you can also wrap it all in a [folder](https://docs.testmace.com/node-types/folder) node or easily combine some of the nodes. This approach is not only more flexible, but also according to the single responsibility principle it allows to use only those features that are needed for a specific task. Obviously, you don't need scripts and tests for sending a request.

# Human-Readable Format of Projects

There is an important conceptual distinction between TestMace and Postman regarding data storage format. Postman stores requests somewhere in your local storage. In case you want to share your requests with other users, you're going to have to use built-in synchronization. In fact, this is a quite common approach, which has its own shortcomings. And what about data security? Some companies' privacy policy might not allow to share personal data with third parties. We believe, TestMace can offer a better solution here, and it's called "human-readable project format".

First, TestMace has such entity as Project. The application itself was developed with ability to store projects in version control systems in mind: the project tree almost completely reflects the file structure, for storing files we use the YAML format (no extra brackets and commas), and every node's file representation is given in the documentation in detail. In most cases, you won't need to refer to it though, because of logical field names.

How can you benefit from it? You can alter your team workflow in a very flexible way, using all common approaches for that. For instance, developers can save the project files in the same repository as backend. As for branches, apart from changing the code base, a developer can also correct existing request scenarios and tests. After committing changes in your repository (git, svn, mercurial, whatever you like more) your favorite CI runs our console utility - [testmace-cli](https://www.npmjs.com/package/@testmace/cli), and the report received (which may, for example, be in the junit format, that is also supported by testmace-cli) is sent to the corresponding system. Thus, the abovementioned data security problem is not a problem anymore.

As you see, TestMace does not impose its ecosystem and paradigm. It easily adapts to already working processes instead.

# Dynamic Variables

TectMace follows the no-code concept: if a problem can be solved without coding, we’re trying to give you this opportunity. Well, working with variables usually does not require you to write code.

For example, we've received a response from the server and want to store a part of it into a variable. In Postman we'd write something like this in a test script (which is kind of weird):
```javascript
var jsonData = JSON.parse(responseBody);
postman.setEnvironmentVariable("data", jsonData.data);
```
Our opinion is that writing a script for such simple and frequently used scenario looks excessive. With TestMace you can do assign a response part to a variable using graphical user interface. Just look at how simple it is:

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/m9f56j3v1rt0k8zhfr3y.gif)

This dynamic variable will now be updated after every new request. Surely, you may argue that postman's approach is more flexible and allows to not only make an assignment, but also do data pre-processing. Let's modify the previous example:
```javascript
var jsonData = JSON.parse(responseBody);
postman.setEnvironmentVariable("data", CryptoJS.MD5(jsonData.data));
```
TestMace has a [script](https://docs.testmace.com/node-types/script) node for this scenario. To do the same in TestMace, we need to send a request and create a script node, using the following code for a script:
```javascript
const data = tm.currentNode.prev.response.body.data;
tm.currentNode.parent.setDynamicVar('data', crypto.MD5(data));
```
As you see, nodes combination works well in this case. For this simple scenario you can just assign the `${crypto.MD5($response.data)}` expression to the variable you create using the graphical user interface.

# Creating Tests via GUI

Postman allows to create tests by writing scripts (in JavaScript). Seems like this approach has no downsides: almost unlimited flexibility, ready-to-go solutions, etc.

But life is life and in reality, QA engineers often don't have any programming skills, but they would like to be helpful. In this case, TestMace suggests you follow the no-code concept and create simple tests via GUI without writing scripts at all. Let's create a test that verifies if some values are equal. This is how it looks like in TestMace:

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/hoxs6yqu4z9v6tb4o10j.gif)

However, you still have an option to [write your tests](https://docs.testmace.com/node-types/assertion-node/script) on your own. There are the same libraries as in a script node and [chai](https://www.chaijs.com/) for writing tests.

# Running Existing Scenario via Link (Link Node)

Quite often you may need to run some request or even a request scenario several times in different parts of the project. For example, a custom multi-step authorization, setup environment, etc. In terms of programming languages, we need to have some functions, that can be reused in different parts of the application. There is the [link](https://docs.testmace.com/node-types/link) node type in TestMace for this purpose. It's very simple to use it:

1. create a request or scenario;
2. create a link node;
3. set a link to the request or scenario created in step 1.

In more complex case, you can specify which dynamic variables should be passed to the above-the-link level. Sounds confusing? Imagine you've created a Folder node named **create-post** and assigned it to the `postId` variable. Now in the **create-post-link** node you can explicitly assign the parent of **create-post-link** to `postId`. This mechanism (again, in terms of programming) can be used for returning the result from a function. Great! DRY in action, and no changes in the code. 
![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/rbdm5p14v7bnknn3212m.gif)
As for Postman, a feature request on reusing [requests has been there from 2015](https://github.com/postmanlabs/postman-app-support/issues/1535), and it seems there are some implications, that they are [working](https://github.com/postmanlabs/postman-app-support/issues/1535#issuecomment-280305898) on it. Now you can change the execution flow in Postman, that, in theory, allows to achieve this behavior, but this is rather a dirty hack, than a working approach.

# Other Differences

- More control over variables scope. The smallest scope where you can define a variable in Postman is the collection scope. TestMace allows to define variables for any request or folder. Postman's Share collection allows to export only collections, while in Testmace sharing works for any node

- TestMace supports [inheritable headers](https://docs.testmace.com/other-features/default-http-headers), that by default may be inserted into child requests. Postman has an [issue](https://github.com/postmanlabs/postman-app-support/issues/1947) on that, and it's already closed, but the solution is... [to use scripts](https://github.com/postmanlabs/postman-app-support/issues/1947#issuecomment-292741840). In TestMace everything is configured via GUI and there is an option to disable headers inheritance in certain children

- Undo/Redo. This works not only while editing nodes, but also while moving, removing, renaming and other actions, that change the project structure

- The files you attach to your requests are a part of the project and are stored together with other project files and synchronize well (as compared to Postman), so you don’t have to choose all necessary files manually every time and share their archives with your colleagues anymore

# Features In Progress

We couldn't resist the temptation to spill the beans on our next releases, especially on these new powerful features, that are being tested at the moment. So, here they are.

## Functions 

As you know, for values generation Postman has so-called dynamic variables. [The list of those variables](https://learning.getpostman.com/docs/postman/variables-and-environments/variables-list/) is very impressive, and the great majority of functions are used to generate fake values. For example, to generate a random email, you should write:

`{{$randomEmail}}`

Since these are variables (even if they are dynamic), they can't be used as functions - they aren't parametrizable, so you wouldn't be able to get a hash of a string.

We're planning to add "real" functions to TestMace. You will be able to access a variable and call a function inside `${}`. To generate a fake email, you'll just have to write:

`${faker.internet.email()}`

This is a function, and you may notice that you can call a method of the object now. Instead of a long flat list of dynamic variables we have a set of logically grouped objects.

And how to calculate a hash of a string? Easy!

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

See, you can even pass variables as parameters! At this point, you may suspect something wrong...

## Using JavaScript in Expressions

... That's right! When we were thinking on functions requirements, we suddenly realized, that we should allow users to use valid JavaScript in their expressions. So now you can write something like this:

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

Do it right in edit fields, no scripts required!

As for Postman, you can only use variables, and if you try to write an expression of some kind, the validator would give a warning and refuse to execute it.

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/fno7ov8ux2kr04zqlcqp.png)

## Advanced Autocompletion

For now, TestMace is equipped with a standard autocomplete feature:

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/m0z5ubb6qxg3uino5noe.png)

As you see, there is a possible line together with what it refers to. This mechanism works only for expressions in `${}` braces.

Note the visual markers for variable types (e.g. string, number, array, etc). You can also switch between several autocompletion modes (for instance, you can choose variables or headers autocompletion). This isn't the main thing though! First, the autocomplete feature works even for expressions (wherever it's possible). This is how it looks like:

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/wq726azm5377y3v3mtaf.png)

Second, it is now available in scripts, too. Just look at it!

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/d4kdzzzq8x3dok1kld0a.gif)

There's no point to compare it with Postman. There you'll find only autocompletion of static variables lists, headers and their values. I may have forgotten something. It doesn't work for scripts :(

# Conclusion

In October we celebrated a year of working on our product. We were able to do a lot of things and, at some point, catch our competitors. Anyway, our goal is to create a really powerful tool for API development. There's still much work to be done. Here's our rough plan for the following year: https://testmace.com/roadmap/.

Your feedback will allow us to work harder on new features, and your support empowers us and makes us believe we're being helpful. Today is a very important day for our project. Today we post TestMace on [ProductHunt](https://www.producthunt.com/posts/testmace). We ask you to support our product, it's very important for us. Oh yes, we have an appealing limited-time offer for you on our PH page!

Also TestMace team has a cool offer for our followers:

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/jn6f9u0et73ql2564prx.png)

Read more on our site [testmace.com](https://testmace.com)