Start United States USA — software Testing Robin, the RPA Programming Language Using Itself

Testing Robin, the RPA Programming Language Using Itself

14
0
TEILEN

The purpose of this article is to show how a programming language can be tested by using the salient features of RPA that are built-in Robin.
Let’s be friends:
Comment (0)
Join the DZone community and get the full member experience.
Software testing in most software houses involves testing web/mobile apps, on-premise, in the cloud or hybrid installations, desktop apps, embedded software/hardware platforms and the like. What about testing a programming language though? How do you approach such a task?
Of course, given the fact there are many popular, tried-and-tested languages out there, there are a plethora of possible approaches but we will attempt to follow a different one (approach) and provide an RPA domain-specific example.
Robin is an RPA scripting language, free to download, install and start creating with it, built with scripting simplicity and process automation in mind. Its modules are decomposed in automation actions, combined with different data-types, statements, functions, exception handling and the appropriate syntax. To provide a real-life scenario we will smoke test the Excel module and give attended and unattended automation options for issuing Jira bugs. Our proposal can be easily extended to other modules and Jira ticket types.
For detailed documentation of Robin’s features please visit the official docs site, here.
We will use Robin to test Robin. A script containing smoke tests for the Excel module will be executed. The Excel module is part of Robin’s standard module library. When bugs are found we will also use Robin to make our lives easier by issuing Jira tickets for the captured bugs.
We are going to showcase both attended automation (in case a bug occurs the user will be prompted via a dialog to select the severity of the issue) and unattended automation (severity will be given directly by the Robin script — we have followed the following logic: Start executing the highest priority tests first and then continue with the lower priority ones._____________________________________________________Note: To replicate the example you need:
You can download the automation scripts and .appmask file, here._____________________________________________________
To automate a process containing UI Elements (either on desktop or web) we need to provide Robin with UI Selectors, describing the elements we wish to manipulate. Robin comes pre-bundled with a UI element capturing tool, called UI Spy.
To capture an element (desktop or web) with UISpy, you must run UI Spy, click on the “Add control” button (which opens a tracking session), move your cursor over the requisite element (it will be highlighted) and hit Ctrl + Left click.
In this example, we are going to capture web elements from Jira, needed for our automation scenario.
This is what a selector looks like:
We can modify the extracted selectors to our will by either using UI Spy’s visual builder:
Or by tampering directly with their CSS syntax. In our scenario, we had to modify the extracted selectors because Jira’s elements change some of their values, after each refresh. Selectors are saved in.appmask files, that can be utilized by Robin scripts.
After extracting all of the requisite elements for our example this is what the .appmask looks like:
Notice we have renamed the application name, screen name and control name to make our selectors easier to use and our scripts more eligible.
Let’s take a look at our automation script step by step.

Continue reading...