How to Build a Test Framework with Rapise¶
Info
In different parts of the documentation and in knowledge base articles we use term Single Test mode to refer to this kind of framework with a parent test and nested sub-tests.
Need to call one test from another? Need to run many tests? Have a test plan? It is time to build a testing framework. Learn how to do it with Rapise.
How Framework Tests Are Structured¶
The Framework in Rapise is a regular test (Framework Root) containing a number of Sub-Tests (Test Cases and Common Features)
Where Test Cases are final test scenarios and Common Features are parts that are re-used and shared between the test cases.
When working with framework, the variable %WORKDIR% always points to the root test case. This helps to find all common assets and files. For example, we always know that we may call Common Feature1.sstest using path %WORKDIR%\Common Feature1\Common Feature1.sstest. So we may call it from any other test case, from other common feature, from library and so on.
Also the same is true for accessing common config and data files. I.e.
Tester.SetConfigPath('%WORKDIR%\\Config.xlsx')
Saving a Framework into Spira¶
The value of framework is in its consistency. There is one important rule that must be followed when saving framework to Spira:
Framework root must be saved first. You need to save it at least once before saving any sub-tests. This will make sure that correct directory structure is defined in Spira.
Once you saved a root test to the Spira, all sub-tests always saved together with it, whenever you do it form the root or from any of sub-tests. Right after saving a root test case you have a framework and may start expanding it.
Saving a Framework into Git¶
If you plan to maintain your framework using Git for source control, please make sure to init git repository at framework root level or higher. Thus Rapise will be able to detect it.
Framework Navigation: Root Test, Parent Test, Sub-Tests¶
There is a number of features intended to help one switching between test and sub-tests.
The Files view shows all nested sub-tests. You may open any of them by double-clicking on the .sstest node:
The test opens in the current Rapise instance. You may also open it in a new window using the Open in New Rapise Window... command from the Context Menu.
You may then switch back to parent test or framework root by using Test/Open Root ...... and Test/Open Parent ..... menu items.
Template Test Case and Clone¶
Usual practice in Framework is to use the Clone feature to produce new sub-tests. So the template test is created and pre-configured (to contain right lib, functions and file references) and then replicated for each next cloned test case.
Calling Other Tests¶
There is a number of ways to call one sub test from another. Usually the test representing a scenario calls another test representing common routine or shared step. It is possible to pass some parameters to the called sub-test.
In most cases you may use Drag&Drop from the Files view into text or RVL editor to generate a call statement.
Executing Full Test¶
From RVL: RVL.DoPlayTest
From JS: Global.DoInvokeTest
Execute One RVL Sheet from Current or Another Test in the Framework¶
From either RVL or JS:
Parallel Test Execution¶
From RVL: RVL.DoPlayTestParallel
From JS: Global.DoInvokeTestParallel
Dropdowns.xlsx¶
Shared Libraries and Shared Functions more powerful with pre-defined dropdowns. For example, you may have a function NavigateToModule used across your framework and switching to an application module. Since we have fixed number of modules in the app (it may be a big number, but still fixed) we may define a dropdown list to make it easier for test creator to navigate without risk of doing a typo and without loss of time to find correct naming.
Dropdowns for Page Objects¶
In Rapise 8.3, we’ve introduced support for a local Dropdowns.xlsx file for Page Objects. This is particularly useful because Page Objects created in Framework Mode can be shared across multiple frameworks, and there may also be Public Page Objects.
Config.xlsx¶
There is a Config file, that may be used for further Global.GetProperty and Global.SetProperty. This is an easy way to read and store various input configuration data: logins, URLs as well as output data (i.e. Internal Invoice ID used in the subsequent test cases).
It is also explained in this video.
Data.xlsx¶
It is typical implement some test cases as data driven. And framework is a great place for storing the shared data files - usually .xlsx spreadsheets. Rapise has built in capabilities for creating and editing such spreadsheets.
Global Objects¶
It is useful to have one or more application specific global objects, sharing functionality needed by majority of test cases in your framework. It may do anything, starting from login and navigation and up to string formatting or text validation.
Libraries¶
One may define a custom library containing common functions, global objects or even rules for test playback, object learning and test recording.
Sharing JS Files¶
Simple way to have common shared logic is to have a common User.js file defining some functions.
For more complex cases, you may have additional .js files and include them in tests.
Profiles¶
Local Web or Mobile Profiles makes it easier to configure the browsers for the whole framework.
WebAppProfile.json¶
For web tests the WebAppProfile may greatly improve the speed and quality of recording. The profile may be defined on the framework root and thus be effective when working on all the contained sub-tests.