DEV Community: Dmitrii Snytkin

JS Community reacts to George Floyd's Death

Dmitrii Snytkin — Fri, 05 Jun 2020 15:44:28 +0000

The killing by Minnesota police of George Floyd grabbed the media's attention recently. Nobody can be indifferent to this heinous crime, and the JS community have also reacted to the incident.

What Happened

The article would be incomplete without a brief description of the event.

George Floyd a black man, died on May 25, 2020, after Derek Chauvin, a white police officer from Minneapolis, knelt on Floyd's neck for 8 minutes and 46 seconds while Floyd was handcuffed face down in the street. Two other officers, Thomas Lane and J Alexander Kueng, further restrained Floyd and the fourth officer, Tou Thao, prevented onlookers from intervening. The incident occurred after Floyd had been arrested on suspicion of passing a counterfeit twenty-dollar bill buying cigarettes at a nearby market. Several witnesses took videos of the incident. The videos that showed Floyd repeatedly saying, "I can't breathe", rapidly spread across social networks and media. All four officers were fired the day after the incident.

We are proud that the JS community leaders have spoken with one voice in this regard and supported the anti-racism movement. Their support is not just bare words. The react.js, express.js, electron.js, and many other communities have asked their users to support organizations and movements which aim to tackle racial inequality. For instance, the Equal Justice Initiative. It is a non-profit organization that is committed to challenging racial and economic injustice and that provides legal representation to prisoners who may have been wrongly convicted of crimes, poor prisoners without effective representation, and others who may have been denied a fair trial.

Below you may see how some of JS community leaders reacted to this crime.

TypeScript

You can see the Black Lives Matter banner on the official TypeScript home page, and the futuristic city turned from bright blue colors to black.

React.js

The React.js community couldn't ignore the event and added the Support the Equal Justice Initiative banner to the home page. In addition to the official community response, many developers from the React Core Team also expressed their support. In particular, they staged a virtual walkout Monday over CEO Mark Zuckerberg's decision not to take action on a series of controversial posts from President Donald Trump last week. Dan Abramov twitted:

Angular

As a gesture of solidarity, the Angular official website is now using a dark color scheme and has the #BlackLivesMatter banner at the top:

The official Twitter account of Angular posted:

Babel

Babel has gone further: on June 3 the official site was shut down and the following message was shown to all users:

The message contains donation links.

Electron

The Electron home page displays the post with the signatures of the Electron community.

In addition to some words of support, there are also the donation links to support the movement and Floyd's family.

TestMace

Our team stands in solidarity with the rest of the JS community and takes unprecedented measures - the light theme is temporary unavailable in the application, and the #BlackLivesMatter banner will appear at the top of the screen after running the app. Current users would also have to use a dark theme.

Conclusion

As you see, the big players of the JS community couldn't be silent and explicitly supported the movement. We are convinced that it is our responsibility, too. In this case, to be silent means to be complicit. To be silent today is to endanger yourself and your family tomorrow. TestMace wishes to express its deep sorrow to George Floyd's family and stands against racial inequality and police brutality.

Let us know about other companies’ support campaigns in the comments below.

What’s new in TestMace part 1. Cloud synchronization, new interface and many more

Dmitrii Snytkin — Wed, 03 Jun 2020 12:07:04 +0000

Hello there! After another long break, TestMace is finally coming out of the shadows to tell you the news about our project.

In case you've forgotten or haven't read the article, TestMace is an IDE for API design. The main purpose of our tool is to cover all possible API interaction cases, such as creating requests, combining them in scenarios (without any code), API description (instead of using swagger and other similar tools), writing tests (no code as well), and so on. The files are wrapped in projects and have a human-readable format. This allows to store projects in version control systems and then use your favorite tools and approaches. This is how it is in a few words. The work to be done is enormous, and at the moment we're still in the beginning of our way. TestMace is ready to help you solve real problems though. Its features allow it to join the lines of the most popular competitors. Since the previous article we've got so many things to tell you, thus we'll divide this information into 2 parts. Let's go.

Beta testing has finished. 💫

As you might have already noticed, the last release hasn't been labeled as a beta one, meaning we have introduced a stable release of our product. From one version to another together with our users we've been doing our best to make our product as much reliable as possible. Currently TestMace is a tried and tested solution, which can be safely used for solving everyday tasks.

New Interface 👻

At the early stages of development, we focused on implementing as many features as possible, paying less attention to interface design. As a result, some users complained of the interface being nonintuitive, while others claimed it to be quite messy (colors, indentations, extra components). After our product hunt release, we were also informed about some UI and UX shortcomings. That's why we've decided to radically redesign the existing interface and focus on beautiful features implementation. And you can already check out our work.

The first thing you're going to notice after running TestMace is its new interface. The changes are quite significant: the standard theme has been improved, and each control has been redesigned. However, if you take a closer look at the interface, you'll see that the structure of interface blocks is the same, so you won't have to get used to it again. The only exception is Folder and Project nodes tabs (that look the same anyway): in order to achieve more compact design, the tab panel is divided into 2 parts: in the left part there is a list of children, while in the right part - the node's settings. You can see the new interface in the picture below:

We've added prompts everywhere else and made the interface much friendlier. Otherwise everything is quite the same, so the migration process shouldn't be painful at all.

Light Theme 🔆

Dark application theme is definitely the latest trend. On the one hand, a dark theme interface looks stylish, on the other hand, in the everyday routine it is easier to work with (both views are subjective though). After all, no doubt the dark theme is a number-one solution for our IDE developers. That's why it's quite obvious, the dark theme was implemented first.

However, we've been getting so many requests for a light theme version recently that we couldn't resist. Now you have a light theme option in the stable 1.0.0 release. Here's how it looks like:

Paid Subscriptions 💵

One of the main features to present is a paid version of our app. We're certain, paid subscriptions would help us make our product more stable and powerful. Still we intend to keep our prices reasonable so that anyone could afford it. We'll be continuously improving the free version of TestMace without limitations on use cases.

If you visit our site, you'll see 4 plans: basic, individual, team, and enterprise.

The first plan is a plain free version, that you've used before. The Enterprise plan is for teams and organizations wanting to get a customized solution. The Individual plan allows individual users to get access to TestMace's advanced features. The Professional plan deserves special attention though.

It's quite simple. Apart from users, you've got teams in the system. Teams are like organizations in Github, for example. You buy a subscription for the whole team. The price depends on the number of users and the chosen period (a month or a year). As compared to the Individual plan, you've got a cloud synchronization feature inside the team. There are no other differences.

There is a dashboard (http://dashboard.testmace.com), that you can use to manage your projects and subscriptions.

The most important, paid version users will get as a bonus:

Cloud synchronization (for 1 user or for a team depending on the plan chosen);
Light theme;
Extended assertions set;
Advanced autocomplete for variables and functions.

There are a few new node types that will also be available in the paid version:

gRPC;
Websocket.

Isn't it cool? Moreover, we offer a trial period for you to try all these wonderful features. It has some differences in comparison with other products' trial periods, such as:

The trial period is not for the whole application, but for each feature separately. For instance, you don't need gRPC, and its trial doesn't start, until you decide to try it. It allows you to fully appreciate all features and stay tuned with the pro-features updates.
The trial period is divided into 3 parts: 15 days for unlogged users, 15 days for authorized users and 30 days for paid subscription users. You can get a 60-days trial in total. This is an opportunity to try our features even without logging in our application.

Cloud Synchronization ☁️

In TestMace teamwork has always been a top priority to us. This is not only a convenient format for storing your projects in version control systems but also a cli for running them in CI/CD and a scenarios sharing ability. Cloud synchronization is one more step towards easier teamwork with API. As stated above, cloud synchronization is a paid feature. However, we've kept it free for individual users.

To be able to use this feature, you'll need to do the following:

Log in the control panel
Create a team
Create a project for this team

Now you're going to need to log in the app and choose the project you've just created. Please note that synchronization process is not performed on the fly. To save the changes, click the Sync button on the top of the toolbar:

You also can migrate existing projects to the cloud. Just click the Save in the cloud button and chose the team which you can save this project for.

Launching the Product on ProductHunt 🚀

Launching a product on Product Hunt is a key milestone for every startup. This site is like a springboard, that can provide a big number of users, useful contacts, and therefore understanding of your future plans. Getting ready for launch is a time-consuming process: you need to find a hunter and influencers, think about getting more users on the launch day (ask regular users for support in particular), create promo materials, etc. Each case is unique.

We started with reading articles about other people's experiences, but they very often contradict each other. This official Product Hunt team post was one of the main sources for us.

As a result, we focused on:

Making a nice profile: find the right tags, name, and description and create an attractive animated logo.
Writing the first comment from developers, where we introduced our team and stated our goals and plans.
Creating makers' accounts and providing some information about them.
Introducing a special offer - LTD Professional version license for 5 people.
Creating a promo-video. This is a very important step, since having an appealing but limited special offer you will always find someone who'd buy your product before actually trying it. Those people will be caught by your promo materials: a video, product description, and landing page.
Creating a roadmap and placing it on the product's site.
Using the Product Hunt Ship service to pre-launch our product. When you create a page on this site, your product appears on the main Product Hunt page from time to time, and you can get new followers. The fact is that you get people who are interested in your product and have a PH account. On the launch day you can use Ship's built-in services to do a mass mailing to ask your followers to support the project. Just don't use the word "Upvote"! Every single user should decide whether they like it or not on their own.
Creating a landing page: we put there a banner with our special offer info and the 'Featured on ProductHunt' button.

We started preparations one and a half month before the launch. We didn't look for a hunter, we decided to do it ourselves. On the launch day we got unexpected news: a few days prior to that a random hunter had published our project! The publication was too raw, it got a very small number of feedbacks and likes and was almost left unnoticed. We immediately contacted the PH support to publish our product again. The PH team approved our request and after a while we were given permission to make a publication the next day, having the previous page deleted.

As a result, we had: one sleepless night, 300+ upvotes, our product on the main page for 1 day, LTD licenses sold, a lot of useful feedback, and several hundreds of new users. Our product wasn't in the first 5 places in the end, but for most of the day we were on the 1st place.

Conclusion ⚡

In this article we've covered some important details of TestMace, which are not directly connected with its features, but make things easier. In addition to that, we've covered such important steps for our project as paid subscriptions introducing, first stable version release, and launching the product on Product Hunt.

In the next article we're going to shed light on new nodes and improvements. Stay tuned!

Why TestMace is better than Postman

Dmitrii Snytkin — Wed, 18 Dec 2019 11:03:07 +0000

Hello, this is Testmace! You might have known about us from our previous articles. For those who have just joined us: we're working on Testmace - an IDE for API design. How are you different from Postman? 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 node is here for you. You'd like to write a script? Use a script node for that. Need tests? An assertion node, here you go. By the way, you can also wrap it all in a 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, 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):

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:

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:

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

TestMace has a 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:

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:

However, you still have an option to write your tests on your own. There are the same libraries as in a script node and chai 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 node type in TestMace for this purpose. It's very simple to use it:

create a request or scenario;
create a link node;
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.

As for Postman, a feature request on reusing requests has been there from 2015, and it seems there are some implications, that they are working 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, that by default may be inserted into child requests. Postman has an issue on that, and it's already closed, but the solution is... to use scripts. 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 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.

Advanced Autocompletion

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

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:

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

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. 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:

Getting Started with API Testing by Using TestMace

Dmitrii Snytkin — Mon, 02 Dec 2019 12:15:54 +0000

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 last overview article. Today you'll see TestMace in action and try out some features of our application.

For more information be sure to look over its documentation - http://docs.testmace.com. Let's go!

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 - admin, password - password;
add a new record;
check if the record was added correctly.

We'll be using the https://testmace-quick-start.herokuapp.com url. It's a plain json server, 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.

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 project (File->New project). 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 Add node -> RequestStep.
Name it create-post. You'll see a new node in the project tree and it's tab will be shown.

Set the following request parameters:

Request type: POST
url: https://testmace-quick-start.herokuapp.com posts
Request body: json with the {"title": "New testmace quick start post"} value.

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 /login, that takes the following json as the request body: {"username": "<username>", "password": "<password>"}, where username and password have the admin and password values respectively. This endpoint returns the following json as a response: {"token": "<token>"}.

Let's use it for authorization. Create a RequestStep node named login with the Project node being its parent. Drag and drop this node above the create-post node in the tree.
Set the following parameters for the newly added node:

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

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 our documentation to read more about variables. This time we'll need user-defined variables.

Define the domain variable with the value https://testmace-quick-start.herokuapp.com at the Project node level. To do that, you need to:

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 login and create-post nodes in particular. To use the variable in the text box, you should write ${<variable_name>}. For example, the url for login will be written as ${domain}/login, and the url for the create-post node - ${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 Parsed tab of the response point to the token in the context menu and select Assign to variable.

You'll see a dialog with the following fields:

Path - the part of a request taken (body.token in our case);
Current value - the value at the specified path (the token value);
Variable name — the name of the variable where our Current value will be stored. (token in our case).
Node — the parent node where the Variable name will be created. Choose Project.

The dialog with complete fields should be the following:

At this point, every time the login node runs, the token variable is updated with the value from the response. This variable will be stored in the Project node and will be available in child nodes, thanks to inheritance mechanism.

To access dynamic variables, use the default variable $dynamicVar. For instance, to get to the saved token you should write ${$dynamicVar.token}.

Passing the authorization token into requests

Previously we've received an authorization token and now we only need to add the Authorization header with the Bearer <tokenValue> value to every request where authorization is needed, including the create-post request.

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 authorization feature.
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 authorization inheritance in TestMace).

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 $dynamicVar.token dynamic variable at the Project node level. Now we have to:

Define the Authorization default header with the Bearer ${$dynamicVar.token} value at the Project node level. To do that, open the default headers dialog (select the Headers 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:

Disable this header in the login 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 Authorization checkbox in the Headers tab in the Inherited area. That's it. The authorization header will now be added to all Project node children, except for the login node. Seems, the scenario is ready, and we only need to run it. To do that, select Run in the Project node context menu.

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 postID) in the create-post node at the Project node level.

You already know how to to that, just go to the Storing the token in a variable section. All we have left is sending a request for getting the post by its id.
Create a RequestStep node named get-post with the following parameters:

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

To go further, you need to take a closer look at Assertion 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 documentation. We'll use a Compare assertion with the equal operator.

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 get-post node.
Open the context menu in the Parsed tab and select 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 title into a separate variable though.
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 repository with this project just for you. Select File -> Open project and choose the Project folder.

Why TestMace has chosen Electron

Dmitrii Snytkin — Tue, 12 Nov 2019 10:40:10 +0000

In the last article we made a short introduction of our product. Today I’d like to tell you why we chose Electron for building our application.

Why Desktop

The web has been growing rapidly for the past 10-15 years. We stumble upon new tools for creating more functional and complex web applications every now and then. There even exist specific programming languages for web development that virtually have no ready solutions for other fields. In our everyday life we have already partially replaced Microsoft Office and Thunderbird with Google Docs and Gmail interface.

However the web can’t yet completely drive desktop out for a number of reasons:

Low web applications responsiveness. It may be caused by either client-server synchronization or poor Internet connection or single-threaded JavaScript or simply your resource hungry browser if your machine is not powerful enough. It should be noted that the problems mentioned above are to be solved, it’s just a matter of time. Web workers, in particular, are already supported by all modern browsers that partially deal with the multithreading problem, and features like SharedArrayBuffer allow to reduce memory copy overhead between the main thread and workers.
Accessing local system resources. There are certain application classes (file managers, tweakers, daemons, and services) that can’t be implemented as web-applications (at least at the current state of their development).
Restricted browser features. For instance, networking is restricted to sending http-request and web-sockets connection only. Lower-level things like tcp, upd-requests are unavailable.
Intentional browser restrictions in terms of security. CORS, working with cookies, headers restrictions.
Limited set of languages and approaches. Unlike web-applications, which are only written in Javascript, for desktop applications it is allowed to use any language up to assembler to achieve efficient use of system resources with the help of multithreading and low-level instructions. One should note that the situation is being improved – say hello to transpilers from some languages to JavaScript. Moreover, compilation to WebAssembly allows to transfer your code from other languages (C++, C#, Rust, etc.) and often to enjoy significant performance improvement.

So, we can conclude that due to the above mentioned reasons TestMace should be a typical desktop application:

We need to get access to the file system to work with projects.
Fetch restrictions do not allow us to get full control over configuring and sending requests.
We might need low-level optimizations to improve performance in the future.

Choosing a Tech Stack

As we decided that our application should be a desktop one, we still need to choose the language and technologies we are going to use to implement it. As for the programming language, requirements are the following:

It should be statically typed.
It should have huge and mature ecosystem: there should be both tried and tested libraries and IDE and other tools’ support.
The majority of the team members must be familiar with the language.

This is quite important. As a startup, we are interested in a fast product launch (in half a year), taking full advantage of internal team resources. Learning a new language and its ecosystem makes planning less predictable and may lead to certain mistakes in decision-making.

Nevertheless, the requirements don’t seem so strict, and some languages as C#, TypeScript, Go meet them. We’ll be choosing technologies taking into account if there are implementations in these languages.

It is way more exciting to choose software for user interface design. Requirements are the following:

It should be multiplatform (Windows, Linux, MacOS)
A full set of build-in and external components
Customizable components
Markdown for interface description
Good support

Now let’s look at some solutions that meet the requirements.

Qt (QML)

Qt is a powerful toolkit for creating multiplatform applications. The latest versions of this framework contain Qt Quick component for writing apps using the declarative markup language QML. QT in general and QML in particular – are battle-tested solutions, that are used in almost all software development fields – from embedded systems to operating system shells.

The main programming language of Qt is C++ (JavaScript can be used in QML). But still there are bindings to Qt and QML for other languages (here is for C#). However, only integration with python is officially supported. Everything else is just a third party’s implementation. And surely you won’t base your application on the library, that was developed by a small team of enthusiasts in their spare time.

There also is Brig – NodeJS bindings for QML. What is so special about the project is its impressive demo. Yet, as it often happens with open source projects, developers do not pay due attention to their product, so it is also out of the game.

GTK

This is a user interface design library, that initially was a part of the GIMP project and then became a separate project. There is the Glade instrument for nice and easy UI development. The main language for GTK development is C, there are bindings for all popular languages though. Besides, MonoDevelop – one of the most powerful IDE for C# development – was created with the help of C# bindings. Unfortunately, going deeper we see that the GTK# project got dusty – the last commit was in February, 2018, then – January, 2017 and 2016. One commit a year. It’s nothing, given the main GTK repository is being actively developed. So close…

Electron

There has been so much fuss about this framework. Some like it for opportunity to transfer parts of their web-applications to desktop, others – hate it for being so resource hungry. Both sides make sense. Electron uses Node.js and Chromium’s rendering library under the hood. Basically, you create a typical web-application and wrap it into an executable file, and every application comes with its own version of Node.js and Chrome.

There is only one major disadvantage – high (compared to other technologies) memory usage: a blank project takes 100-200 MB. Some would consider that to be a reason against the apps like that (hello, Skype). But let’s analyze the market. A lot of popular applications are built using Electron (Slack, Skype, Discord, VSCode, Atom, Postman, Insomnia, etc.). Many of them are standards in their fields or are conquering users’ hearts (VSCode and Insomnia, for instance). People just use the tools that are good at solving their everyday tasks and ignore some side effects. On the other side, machines are getting more and more powerful (at least, RAM continues to climb), and less clients complain that “Chrome eats all RAM.” In summary, we reckon high memory usage will be quite irrelevant if the product can do the job well enough.

The advantages of Electron are quite obvious:

Some things from the web-application can be reused.
It is easier to find professionals in this sphere.
A proven workflow ‘designer – layout designer – developer’ with plenty of useful tools for every stage.

Another benefit of ours is that the team has substantial experience in front-end development.

We eventually decided to go for Electron as the main tool to develop our project. That also means we had to choose the TypeScript language for our application.

Conclusion

One of the main goals of the startup is the fast product launch, and, of course, we’d like to minimize the costs. This review was aimed at finding the tool that would help us in that. We believe, Electron is the best choice here. It’s been 1 year since we’ve started working on the project, and Electron still has no rivals. It seems we’re getting serious here 🙂

💥 Bonus 💥

Also we’re glad to give you 👉 special 50% exclusive offer 👈 for TestMace professional version which includes a built in cloud synchronization for you team! The promo code is: ELECTRON_BETTER. Promo code is valid for only two days! Have time to try the full power of professional tool for working with API! 💪

We Built an IDE to work with API Design. Here's What We Did

Dmitrii Snytkin — Thu, 07 Nov 2019 09:44:47 +0000

Hello there! Today is the day when we’re ready to present to the IT community TestMace, our IDE for API design. Some of you may know about it from the previous article. However, we haven’t yet provided you with an overall review of our tool, so here you go.

Motivation

We’d like to start by telling you the story on how we ended up with this feeling of creating our own advanced API tool at the first place. Here’s the list of features we suppose every IDE for API design should have:

creating and sending requests and scenarios (request chains);
writing different kinds of tests;
test generation;
working with API description, including importing fromSwagger, OpenAPI, WADL, etc.;
mocking requests;
great support of one or several scripting languages and integration with the most popular libraries;
and so on.

Follow your preferences to complete the list. Apart from IDE, it is also quite important to create a specific infrastructure like cloud synchronization, CLI tools, online monitoring service, etc. After all, the latest trends are about not only powerful features, but also a nice interface.

Who will benefit from it? Apparently, those who are in any way connected with API development and testing, developers and testers in particular. While developers are often limited to sending single requests and running simple scenarios, in their main tool testers are going to need something more advanced, including powerful features for writing tests and ability to run them in CI.

Having all that in mind, we started designing our product. Let’s look at what we have achieved so far.

Quick Start

Let’s start with simply looking at our app. You can download it from our site. For now, all 3 main platforms are supported – Windows, Linux, and MacOS. Download the app, install it and run. Running it the first time, you’ll see this window:

Click on the + button in the top of content area to create your first request. The request tab should look like this:

Let’s take a closer look at it. The request interface resembles popular rest clients interface, which makes migration from that kind of tools easier. Let’s send our first request to https://next.json-generator.com/api/json/get/NJv-NT-U8

Apparently, the response panel has nothing to surprise us with. But still you have to know, that:

The response body represents a tree, that makes it more informative and allows to add some curious features described down below.
There is the Assertions tab, that has a list of tests for this particular request.

As you can see, our tool can be used as a well-organized rest client. But sending requests is not what we’re here for. Now let’s talk about the main features and concepts of TestMace.

TestMace’s Main Features and Concepts

Node

TestMace’s workflow is distributed into different node types. The previous example illustrates how RequestStep node works. Some other node types are now available in the app:

RequestStep. This is a node that you use to create a request. It can have only one Assertion node as a child element.
Assertion. This one is used for writing tests. It can be a child node only for a RequestStep node.
Folder. It allows to group Folder and RequestStep nodes under it.
Project. This is a root node, that is created automatically when you start a new project. It is functionally identical to a Folder node.
Link. This is a link to Folder or RequestStep nodes. It allows to reuse requests and scenarios.

You can find nodes in scratches (a bottom left panel for quick creating one-time requests) and in project (a top left panel), that I’m going to show you next.

Project

After running the app, you can see a Project line at the top left of the screen. That is the project tree root. When you run your project, a temporary project is created, and the path to it depends on your operating system. You can change it whenever you want.

The main purpose of the project is to give you an ability to save your drafts in the file system, synchronize it via the version control system, run scenarios in CI, review changes, etc.

Variables

Variables is one of the core mechanisms of our app. Those of you who work with TestMace-like tools might already have it in mind. Variables is a way of saving shared data and communication between nodes.

Environment variables in Postman and Insomnia are a great example of this. But we have gone beyond all that. In TestMace you can define your variables at the node level. Any node. There is also a mechanism of inheritance variables from parents and overriding variables in child elements. In addition, there are several default variables, which names start with $. Here are some of them:

$prevStep – a reference to the previous node variables;
$nextStep – a reference to the next node variables;
$parent – a reference to the parent node variables;
$response – a server response;
$env – current environment variables;
$dynamicVar – dynamic variables, that are being created during scenario or request run.
$env are basically just the Project node variables, but the variables set is different for every environment.

You can access a variable using ${variable_name}. The value of that variable might contain another variable or even an expression. For instance, an url variable value may be the following:

http://${host}:${port}/${endpoint}

It should be mentioned, that you can assign variables while running scripts. For example, quite often it is important to save authorization data (a token or full header) that come from the server after a successful login. TestMace allows you to store that data in parent’s dynamic variables. To avoid collision with existing static variables, dynamic variables have been placed in a separate object – $dynamicVar.

Scenarios

Taking advantage of the features stated above, you can run request scenarios. For example, create an entity -> request an entity -> delete an entity. In this case, you can use a Folder node to group several RequestStep nodes.

Autocomplete Feature and Expression Value Highlighting

To make working with variables more convenient, we added an autocomplete feature and variables’ values highlighting, that shows you what value each variable has. A picture paints a thousand words here:

Note that not only variables, but also such things as headers, some headers’ values (like Cotent-Type), protocols are autocompleted. With development of our product, the list is regularly updated.

Undo/Redo

Ability to undo/redo changes is a practically useful feature, yet not every tool comes with it (including API tools). We’re here to change it! Undo/redo works within the whole project, which allows you to undo not only changes to a particular node, but also its creating, deleting, moving and so on. The most critical operations need to be confirmed.

Creating Tests

Assertion node takes care of creating tests. One of the major features here is creating tests without programming using build-in editors.

An assertion node is a number of assertions, each of which has its own type. There are several types:

Compare values – it simply compares two values. We have several comparison operators: equal to, not equal to, greater than, greater than or equal to, less than, less than or equal to.
Contains value – checks if a substring is present in a string.
XPath – checks if there is a certain value in XML via selectors.
JavaScript assertion – a random JavaScript script that returns true on success and false on failure.

Note that only the latter requires some programming skills, the other three are created with the help of graphical user interface. Here is an example of creating compare values assertion dialog:

Quick assertions creation right from the response would be our icing on the cake. Just look at this!

However, these assertions clearly have certain limitations, so you can use javascript assertions. Here TestMace provides you with a nice environment with autocomplete feature, syntax highlighting and even static analyzer.

API Description

TestMace allows not only to use API, but also to write documentation. The description itself has a hierarchical structure and fits the project naturally. In addition to that, you can import API descriptions from Swagger 2.0 / OpenAPI 3.0 formats. The description is not left aside, but fully integrates with the project: autocompletion of urls, HTTP headers, query parameters is available, and we’re planning to add tests to check if a response matches API description.

Nodes Sharing

Let’s say you need to share a bugged request or scenario with a colleague or just attach it to the bug. TestMace’s got it: it allows you to serialize any node or a subtree in url. Just copy-paste and you have your request shared with another machine or project.

Human-Readable Format for Project Storing

Each node is stored either in a separate .yml file (like Assertion node is) or in a folder with the node’s name containing index.yml file.
That is how the file with the request from the previous example looks like:

children:  []
variables: {}
type: RequestStep
assignVariables:  []
requestData:
  request:
    method: GET
    url: 'https://next.json-generator.com/api/json/get/NJv-NT-U8'
  headers:  []
disabledInheritedHeaders:  []
  params:  []
  body:
    type: Json
jsonBody: ''
xmlBody: ''
textBody: ''
formData:  []
    file: ''
formURLEncoded:  []
strictSSL: Inherit
authData:
  type: inherit
name: Scratch 1

As you can see, it’s totally readable. You can easily edit it manually if you need.

The directory hierarchy is the same as the nodes hierarchy. For example, this scenario:

Is mapping in the file system to the following structure (only directory hierarchy is shown, but it should be clear):

That simplifies the project review process.

Import from Postman

Having read all this, some of you may be wanting to try out our new product (aren’t you?) or even use it in your project (why the hell not). Well, you must be hesitating since you’ve got all your work done in Postman. In this case, TestMace supports importing collections from Postman. It is without tests for now, but we may include it in our future releases.

Our Plans

We’re hoping after reading all this many of you have found our product interesting. And it’s just a beginning! At the moment we’re fully involved in developing and I’m going to tell you about what we’re going to do next.

Cloud Synchronization

That’s one of the most desirable features. Now we suggest you use the version control system for it, working on making everything in our app compatible with it. However, some of you may not be particularly happy with this workflow, so we’re planning to add cloud synchronization mechanism that you used to.

CLI

As I already mentioned, it’s hard to imagine any IDE product without integration with existing projects or workflow. CLI is essential for integrating tests written in TestMace into continuous integration process. We’re currently working on it, but in our early versions projects will run with a simple console report. In the future you’ll see reports in JUnit format.

Plugin System

Despite all functionality, our product can’t cover all possible use cases. Each project is unique, and there may be too many specific tasks. That is why we’ve been thinking to add SDK for plugins development, so that each individual user could meet their own needs.

New Node Types

Some use cases may require more node types, than we have now. We’re planning to add:

Script Node, which transforms and stores data using js and the corresponding API. This node type might be useful for writing something like pre-request and post-request scripts in Postman;
GraphQL Node for graphql support;
Custom Assertion Node to expand the set of existing assertions in the project; The list is definitely not complete yet, and your feedback would help us update it.

FAQ

How is your product different from Postman?

The node concept allows to scale your product functionality with no limits.
The human-readable format of the project and storing it in the file system makes it easier to work with the version control system.
Creating tests without programming and advanced js support in the test editor (autocomplete feature, static analyzer).
More sophisticated autocomplete feature and highlighting of current variables’ values.

Is this an open-source product?

No, source files are not available, but in the future we’re considering to add this option.

What are you living on? :)

Along with the free version, there will soon be a paid one. It’ll first of all include the features, like synchronization that require the server side.

Conclusion

We’re working hard to finally release a stable version of TestMace. We’ve received a positive feedback from our first users, so you can already safely try out our product. We would really appreciate your feedback as well, since it is impossible to create a great tool without close cooperation with the community. Contact us:

Official site: https://testmace.com
Telegram: https://t.me/testmace
Slack: https://testmaceslackin.herokuapp.com
Facebook: https://www.facebook.com/testmace
Issues-tracker: https://github.com/TestMace/TestMace-issues

We’re looking forward to your comments!