Getting Started with Rapise for Automated Testing

January 22nd, 2015 by inflectra

So lets assume you have read the other articles, and know how to learn objects in Rapise. What do you do now? How do you run and modify a test? The answer depends on the method used to create the test.

Learning Through Doing

If you used the methods described in the entry, “Rapise - learning through doing” you are over 90% of the way there. You will have learned objects and a created well structured test to perform the actions previously recorded. If you followed one of the other methods, you will need to think out your plan for flow, data, expectations, and process.

We would recommend, for your first tests, that you learn the objects and actions using the native recordings. Yes, there can be a good case made for each of the other types of learning, but they do not provide the illustration on how to manipulate a test to your plan. Once this test recording is made there are several standard parts of the file structure.

The Test Folder Structure

The structure is one based on folder and file. The main folder contains the name of the test, several files which make up the definition of the objects learned (objects.js), the definition of the use case, and definitions provided by the user:

On the left side of Rapise, by default you are dropped into the Object tree. In this view you can expand on any of the objects within the application that you have learned. Each of those objects will have a name, and if you expand them it will also have a set of actions which can be performed:

Test Scripting Format

In the main area, editor, of Rapise, you should see some code that defines the actions you have performed while recording. We suggest studying this as it will assist you in understanding the syntax of a test and will allow you to do much more in the future. The code is a variant of JavaScript (technically Microsoft JScript) and can be manipulated by hand with intellisense and code folding provided by Rapise.

At each action you will see a description and a command, something like this…

//Press button '1'
SeS('_1').DoAction();

The line starting with the “//” is the description of the step and should match up to the action performed. The next line is the command that actually performs the action. We won't go too deep here but we will explain the parts.

  1. First you have the command “SeS” which defines this as a Rapise action (it was called SeS because it stands for Simple engine Scripting).
  2. Next you have the definition of which object to interact with surrounded with single quotes parenthesis, (’_1’)
  3. This is followed by a “.” to separate the object definition from the next part
  4. The action definition and any parameters it requires. In the example, “DoAction()” parameters would go inside the parenthesis
  5. And finally a semicolon “;” to finalize the step

These steps can be reordered, changed, and modified by simply editing this .js file. There are lots of different actions available to the test developer as they develop skill in using Rapise. One can make a number of validations or interactions to meet the requirements of the test plan.

Without altering the test, you should be able to just click on the “Play” button to run your test. Watch how it interacts with your application. Once it is finished you will be taken to the report page. For now disregard the report and select the test file again. Make a few modifications by copying and pasting code around, you can alter the flow of the recording and playback. Run the test again and review the differences.

Here we are just starting with Rapise, there are many more things to learn. In the next several articles we will explore more in depth analysis of how alterations are made and start building more complex interactions.

rapise scripting tutorial recording playback

Spira Helps You Deliver Quality Software, Faster and with Lower Risk.

Get Started with Spira for Free

And if you have any questions, please email or call us at +1 (202) 558-6885

Free Trial