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:

1. The response body represents a tree, that makes it more informative and allows to add some curious features described down below.
2. 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:

• This is a node that you use to create a request. It can have only one Assertion node as a child element.
• This one is used for writing tests. It can be a child node only for a RequestStep node.
• It allows to group Folder and RequestStep nodes under it.
• This is a root node, that is created automatically when you start a new project. It is functionally identical to a Folder node.
• 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:

1. 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”.
2. Contains value – checks if a substring is present in a string.
3. XPath – checks if there is a certain value in XML via selectors.
4. 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

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?

1. The node concept allows to scale your product functionality with no limits.
2. The human-readable format of the project and storing it in the file system makes it easier to work with the version control system.
3. Creating tests without programming and advanced js support in the test editor (autocomplete feature, static analyzer).
4. 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://client.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!

The Project

We have already given the definition of the project. Basically, it is no different from one of any typical IDE, graphics editor and other apps. A TestMace project is stored in the file system, and due to a human-readable format it allows to monitor changes using the version control system.

The project tree is located on the top of the sidebar, and a temporary project is created in $AppData/tmp-project directory during the first run and after creating a new project ($AppData depends on your OS). The project can be saved in any other directory, if necessary (use the File menu actions). In our example the project tree looks like this:

Note that at the moment all nodes are runnable. It means that:

1. When running the RequestStep node, the pre-configured request is sent.
2. When running the Folder and Project nodes, all nested nodes are run successively.
3. When running the Assertion node, this node’s assertions are executed.

To understand our project better, let’s see the example. We’ll use this project, that is deployed at https://testmace-stage.herokuapp.com. This open source project is a very convenient solution for client testing.

Here we are interested in the posts resource of the project. It fully supports CRUD, so let’s imagine we need to create the following scenario:

1. Make a post with a certain title. Get the post with an id in response.
2. Check if the post with the given title was made.

Let’s go. As we mentioned earlier, a Folder node is a great choice for grouping nodes. What is interesting about this Folder type, is that the nodes within it are run sequentially that allows to group them into scenarios.

Now add a folder “posts” to the project and then add a subfolder “create”. You can do it via the context menu of the chosen parent:

In our case, the project tree will be like this:

According to our scenario, we need to send a request for making the post first. This request is going to have the following parameters:

• URL https://testmace-stage.herokuapp.com/posts
• POST Method
• A Content-Type header with application/json value
• The body {“title”: “My first TestMace post”}

Well, let’s create a RequestStep node with these parameters. See what I’ve got:

As you can see, the server says the post was created, but I want to check it to be sure.

Obviously, to do that we need to fetch this post by its id. So we are to make the following request:

• URL https://testmace-stage.herokuapp.com/posts/${id}
• GET method

But how do we get the id? We can do it using the default variable $prevStep and going back to the previous step. The full path to our id will be $prevStep.$response.body.id. So this is how our result request look like:

As you see, the id was passed correctly. Now all we need is to add an Assertion node to check the scenarios automatically. In the previous article we showed you a quick way to create an Assertion node from a parsed response. Here’s a gif for it:

Nice! We have created a scenario and a test. Now we just run the create folder (or any other parent, including the Project node) and we can run the scenario.

We have just one step left to make our project perfect. The thing is that “My first TestMace post” title can be seen in at least two places – in the first request and in the Assertion node. Copy and paste is never a good job, since if you want to change the post title, you are going to have to do that several times, and there is a chance that you can forget to change something.

This problem can be solved with the help of variables mechanism. Let’s define the title variable and use it in our nodes. We’d better do it in the create folder, as we’ll be able to use our variable in any child node, thanks to variable inheritance mechanism. As you homework, try to create and use this variable 🙂

One more thing to say here is that using this test, you can be confused to find a useless entry after its run. To avoid this side effect and test another functional part of your application you can

add one more RequestStep to your scenario that would send a request to delete a just created entry and additionally create a test that would check if the entry was deleted.

Project Storage

One of the benefits of TestMace is a human-readable format for storing your projects. Each node is stored in a separate folder or file. We use the YAML format for storing files.

Now I’ll show you how TestMace works with project files. In our project’s file system the directory hierarchy is the following:

As you see, the directory hierarchy is almost the same as the nodes hierarchy. Let’s look at how the Project node is stored. As we know, this is the root node of the project. In the file system it is stored in the index.yml in the Project folder. It looks like this:

type: Project

name: Project

environments:

  active: null

  environments: {}

children:

 - posts

variables: {}

authData:

  type: inherit

settings:

  proxy:

    enable: false

version: '1'

• type has the node type (Project, Folder, RequestStep или Assertion). All node type files have this field.
• name has the node name.
• children has an array of children and also defines their order.

Other fields will be described after we state the main features, but their names speak for themselves.

Now we go on. The project node contains the posts node with the index.yml file in it, which format is pretty similar to one of the Project node.

See the create node as an example of variables storage. If you were successful in passing the “My first TestMace post” title to a create node’s variable, then you’ll see it in the file system:

children:

  - create post

  - check post

variables:

  title: My first TestMace post

cookies: []

type: Folder

authData:

  type: inherit

name: create

Nothing special, just an ordinary key-value storage.

The RequestStep node has pretty much the same story with its storing – the node folder contains an index.yml file. This is how the file of the make-a-post request looks like:

children: []

variables: {}

type: RequestStep

requestData:

  request:

    method: POST

    url: 'https://testmace-stage.herokuapp.com/posts'

  headers: []

  params: []

  body:

    type: Json

    jsonBody: |-

      {

        "title": "${title}"

      }

    xmlBody: ''

    textBody: ''

    formData: []

    formURLEncoded: []

authData:

  type: inherit

name: create post

No comments here, it seems obvious.

And the last node here to talk about is the Assertion node. It is stored as an yaml file in the parent RequestStep folder and has a corresponding to the project assertion node name. We have only one Assertion node in the project and it looks like that:

children: []

variables: {}

type: Assertion

assertions:

  - disabled: false

    type: compare

    actualValue: '${$response.body.title}'

    operator: equal

    expectedValue: '${title}'

name: Assertions

Here we are interested in the assertions array. Each entry format in assertions is different and depends on the assertion type. However, disabled and type fields are shared. That’s it, there’s no need to describe other obvious things.

Conclusion

We did a great job today! We created a very common scenario and tested it. Note that you didn’t have to write any code here, but if you used another app you would have! This is what our purpose is. We want to create a powerful but at the same time simple tool for API testing. And I think, we’re halfway there, aren’t we? 😉

Your First Launch

Launching the product the first time, you will see:

Let’s look at each interface part closely.

You can see a toolbar at the top of the screen. So far you can do the following:

1. Undo and Redo your actions. At the moment all actions on changing projects and nodes are supported (see below).
2. Work with cookies via the Cookies Dialog.
3. Configure and choose your environment.

The main interface of the application is divided into two parts – a sidebar and a workspace. The sidebar has the top and bottom sections:

The top section is intended for working with the current project.

The project is a hierarchical set of nodes that are connected physically and logically within one directory. We’ll provide more details on working on the project in the next article.

There is also the Scratches panel on the sidebar, where temporary (or “quick”) user requests are saved.

And the final part of the interface – workspace – is right in the middle of the screen. Now it’s empty, but let’s create our first request to make it look better.

Node Types

A node is an entry in the scratches list or any element of the project tree. There are several node types:

• RequestStep. This is a node that you can use to send 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.

In Scratches you can create only RequestStep and Assertion nodes, while you can add any node types to the project and build hierarchical structure of any complexity. Moreover, using Folder nodes, you can even create request scenarios and test them via Assertion. This will be described below.

Our First Request

To create a request you need to click on +, that is right under the toolbar:

Then you’ll see the request configuration interface, and a new entry will be added to the Scratches panel:

Congratulations, you’ve just created a draft request! Now we only need to configure it. The TestMace request configuration interface is quite similar to one of other HTTP clients, so there’s no need to go into it now. Just note that the interface is visually divided into two parts: one for request configuration and another for viewing response results.

Let’s send a request. I use https://next.json-generator.com for testing, since it helps to create different JSON structures and enable access to them from the outside. Now, as we usually do, let’s say hello to this world and create a JSON like that:

{

     "action": "Hello",

     "who": "World"

}

Create a link for it. I have this one https://next.json-generator.com/api/json/get/EJvQVEVGL Then paste it to the URL field and push the RUN button. The result should be the following:

The app should say the request was successful and display brief statistics on the request execution time and response size. In the response panel you can see parsed and text (with or without highlighting) responses.

Variables

The Variables section is a key-value storage for storing and reusing some data. It is often used for removing code duplicates and improving readability: The greetingUrl variable says more than just the line https://next.json-generator.com/api/json/get/EJvQVEVGL for sure.

Variables mechanism is very well integrated to all application parts and has several features:

• Variables can store strings, arrays or objects.
• Variables are defined for each node and are inherited from parent nodes.
• Variables’ values can refer to other variables.
• Default variables names start with $. There are the following default variables:
  • $parent – a reference to a parent node
  • $prevStep – a reference to the previous node within a Folder node
  • $nextStep – a reference to the next node within a Folder node
  • $env – a reference to the environment variables (in terms of our application)
  • $response (only for RequestStep and its children) – a reference to a response from the server.

There is the Variables button in every node interface, that opens the variables definition dialog.

It’s time we put all that into practice! First, we get back to our hello-world request and try to put the URL into a variable. As you remember, the URL is https://next.json-generator.com/api/json/get/EJvQVEVGL. Now open the variables configuration dialog and add a variable named greetingUrl having our URL as a value. This is going to look like this:

Click OK and change the URL to our new variable. The syntax is: ${variableName}. In this case we’ll get:

Please note that the autocomplete feature is available for variables. This is how it works:

Besides, you can check what value your variable has at the moment. You just have to point to the variable!

Sending the request one more time, we can make sure that the URL value is successfully inserted from the variable.

Assertion Node

As mentioned above, this node is used for writing tests and can only be a child of a RequestStep node. There are two ways to add an Assertion node to your project:

• Right-click on the parent node in the sidebar

• In Assertions tab on the response panel

We’ll go with the second option. Click CREATE NEW ASSERTION NODE and an Assertion node will be added as a child node, and the interface will be changed to the add-assertion interface.

Assertion in the assertion node is just a conditional check. Let’s suppose we need to check if the server responds “Hello” in the action field. So far the assertion list is empty, let’s add our first test. Click on ADD ASSERTION and you’ll see the Assertion node interface. There is a template for an assertion:

Let’s have a closer look at the interface. Each assertion has a type. There are 4 assertion types:

1. 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”.
2. Contains value – checks if a substring is present in a string.
3. XPath – checks if there is a certain value in XML via selectors.
4. JavaScript assertion – a random JavaScript script that returns true on success and false on failure.

As you can see all inputs use variables mechanism as well.

Okay, let’s get back to our little project. Action field value can be received by response using response.body.action. We expect to receive the value “Hello”. So our assertion looks like that:

Fine. Click RUN for a test run. If it is successful, our assertion will be highlighted in green, if not – in red. If you do everything right, you’ll definitely see green color.

TestMace can also correct errors. Don’t you believe in magic? Just watch those hands 😉 Let’s change “Hello” in the expected value field to “Bye”, for example. After the run the system says that the values are not equal:

As you might have noticed, the Disable Errors and Fix Errors buttons are active (the same happens when you point to the assertion):

• Disable Errors disables the assertion, so it will not be executed in the following runs.
• Fix Errors fixes errors. Fixing errors behaviour depends on the chosen assertion type, and sometimes to fix error is not possible.

Click the Fix Errors button… and voila! The value has been transfered from response to expected value. If you run it again, the test will be successful.

In conclusion, I’d like to show you one more nice feature, that allows to quickly create assertions. In TestMace you can create an assertion right from a received response. Just right click on the response field and choose an appropriate assertion from the context menu.

Then the fully configured assertion is created and you just have to click the RUN button.

Conclusion

In this article we described the main features of the interface, as well as configured a request and tested it. However, that is just a tiny piece of all that TestMace can do. We’ll focus on another features in the next articles. Stay tuned 🙂

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:

1. It should be statically typed.
2. It should have huge and mature ecosystem: there should be both tried and tested libraries and IDE and other tools’ support.
3. 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:

1. It should be multiplatform (Windows, Linux, MacOS)
2. A full set of build-in and external components
3. Customizable components
4. Markdown for interface description
5. 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:

1. Some things from the web-application can be reused.
2. It is easier to find professionals in this sphere.
3. 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 3 months since we’ve started working on the project, and Electron still has no rivals. It seems we’re getting serious here 🙂

Dealing with API development and API testing, we played around with lots of different tools, as there are dozens of them these days. Some of them are quite good, powerful and beautiful indeed. Switching from one tool to another, we faced various problems and disadvantages, most of which we were able to solve. Despite this, we couldn’t help feeling that there is no perfect tool for us yet 🙂 Now while you are reading this, we are working on our wonderful tool for API development and testing! Our application will allow not only to quickly configure and send requests using powerful features, such as variables, scope, and data entry fields with highlighting and autocompletion of every single thing, but also to write autotests using a very nice and simple test builder. We are planning to create a tool that will prove useful to both developers and testers, helping to improve interaction among team members.

2. About the Product

In the very first version of the product we tried to lay the foundations for the future usability of the tool. For instance, we implemented the variables mechanism, that allows to define both global and node scoped variables. Variables help to store and reuse any data in any part of the app in the same way.

This mechanism provides an opportunity to work with complex scenarios, that might be useful in automated use case testing, as well as in performing non-standard authorization and other things. In our application it is possible to create scenarios like these by grouping certain requests and running them automatically, referring in every new request to the results of the previous ones and using any described entities with entities reference.

Syntax highlighting and autocomplete feature help while working with variables. Every text box is equipped with these to significantly improve usability and make the process of configuring requests faster.

We also paid considerable attention to the Undo/Redo function. We made it work in different parts of the application. For example, you can undo the changes you made in a particular request or even in the project file structure. One of the most important features of the tool is the project storage format. Your requests and scenarios structure mirrors the project structure in the file system, and there is a special format for requests and tests, that are stored in separate YAML files. This is for developers and testers to work together on the same project, using the version control system and tried and tested in developers’ environment code review practices.

For this purpose they will be advised to use special import/export mechanisms to support some standard formats, that you can find in other popular tools. Moreover, the Share button will help quickly send your configured request to a colleague. You can also choose from different automation testing strategies: either use a graphical test generator or write your own Javascript test with your favoriteJavascript libraries.

In addition, we are planning to implement such great features as API import with Swagger and WSDL support and automated test generation based on API documentation. First, we’ll deal with smoke, boundary and security tests generation, then hope to suggest a solution for more complex test.

3. Our Team

Our team is our pride and the main achievement. Each of us is a professional software developer, having solid experience in the field. Our knowledge and desire to make our work and work of our colleagues more convenient are pushing us to improve our product faster.

4. Future Plans

The main goal for us today is to release a beta version of the product. I suppose, the first is going to be a closed beta, so we’d appreciate if you could try a new tool out in your work and help us with your feedback. You can become a beta tester here: beta.testmace.com. We are starting our closed beta in January, 2019. The following two months will be devoted to analyzing your comments and suggestions to present our tool to the community in April. We realize though, that our tool is short of some features that might seem essential for the great part of users. For instance, in the first version of the tool team members can work on tests and scenarios together only by using the version control system. Solutions like this allow us to get a prompt feedback, providing enthusiasts with flexibility and letting them solve day-to-day problems right now. Our global plans include considering the whole API life cycle, expanding our tool functionality, and creating new tools for API documentation, monitoring and testing.

5. Our Message to You

For us professional software developers and QA engineers are the most valuable source of knowledge for defining requirements and implementing functionality of our product. We suggest you take part in its development. For this, we create and introduce special tools, such as the feature request system with a voting function, the public bug tracker with a participants motivation system, and so on. Your name will also be displayed in our acknowledgments section 🙂 And don’t hesitate to email us your comments and suggestions at beta@testmace.com. Make sure to follow us on social media:

• Instagram: https://www.instagram.com/testmace/
• twitter: https://twitter.com/testmace_soft
• facebook: https://www.facebook.com/testmace/

Thank you in advance!