Rapise 8.3 introduces AI-powered capabilities for executing test cases. To leverage this feature, integrate the AiTester public page object into your framework. With AiTester, you can send text and image-augmented queries to AI models hosted by OpenAI, Azure OpenAI, and Amazon Bedrock. Example applications include generating data, performing image-based verifications (e.g., detecting discrepancies or counting visual elements), and more.
In the KB62 article - Accessing Files using Rapise we explain how to access the names, versions and locations of files on the Windows file system. One customer asked - can we verify any file details other than version. This article provides sample code for accessing other information.
Note: if you have Rapise 5.5+ then you may simply use File.Info action.
One of the challenges using an automated testing tool is to organize things in a way that it is logical enough to find something quickly, structured enough to avoid duplication and simple enough to maintain and upgrade.
This statement is also true for Rapise objects. A common requirement is to deal with the same objects within a flow of different test cases. For instance, if an application has “Log In” functionality then many, many tests will require logging-in and logging-out. Each test will have this object in its own object tree. However this causes trouble if a change in the application affects the recognition of the Log In object. All of the test cases will need to be updated. In such situations it is much more convenient to have the “Log In” objects placed into their own file and re-used by other tests.
This article is obsolete. In Rapise 8.0 and above the recommended approach is to use Page Objects / Modules.
Sometimes it is necessary to examine the state of an object. For example, determine if Toggle Button is pressed or not, Radio/Check Button is checked or not, etc. This guide describes a couple of different ways of achieving this.
Sometimes Rapise will incorrectly recognize a GUI component. This guide outlines how you can manually change the object type captured during recording.
It is often useful to have a common set of code libraries and objects that can be reused amongst multiple tests. With Rapise this can be done by creating a common test and then including it into the other actual tests. However due to the way REST web service tests are stored, there are some slight changes needed to handle REST services. This articles describes the process.
Note: if you have Rapise 8.0+ there is a simpler way, just create a module for REST service calls.
This guide describes what simulated objects are and when they should be used.
Often you want to be able to query for the child elements on a web page that are dynamically created and therefore not good candidates for LEARNing individually. This article explains how you can use the dynamic XPATH methods of Rapise to accomplish this task.
Sometimes using Rapise you need to access files on the Windows filesystem, either for testing purposes, or to object test data stored in a flat CSV, TSV or text file. This sample illustrates how you can access the File System using Rapise and the Windows FileSystemObject (http://msdn.microsoft.com/en-us/library/aa242706(v=vs.60).aspx).
Alternatively you may also use File global object.
Simulated objects are found by looking at the parameters of the object (x number of pixels from the top of the window, y number of pixels from the left of the window, etc). One common question that has arisen is - during playback, does Rapise take into account screen resolution? If the resolution on the computer you run it on is different from the one it records on the location of the object will change relative to the number of pixels. So on the computer you record it on the top parameter might be 200 but on a different resolution it might be 180. Would Rapise recognize that the resolution is different and adjust for that?
This article describes how to access child objects of a Learned Java AWT/Swing object when using the Rapise Java library. Sometimes when you Learn a top-level object, you want to be able to programmatically query the object to locate the child objects that are visible in the Java Spy.
Often you need to be able to check for the presence of an object and then depending on whether the object is visible perform one of two possible sets of operations. This article explains the recommended way of doing this in Rapise 1.5.
When using Rapise to record test scripts against Windows, Java, Flex, or other thick client applications that have windows or objects whose names may change in between test runs, you will usually need to make changes to either the test script or the learned objects so that they can match correctly. This article outlines some suggested techniques for recording/playing back scripts against such applications.
It is often useful to have a common set of code libraries and objects that can be reused amongst multiple tests. With Rapise this can be done by creating a common test and then including it into the other actual tests. This article describes the process.
This article is obsolete. To get information on how to use common functions and objects across test cases please refer to Frameworks (recommended, requires Rapise 8.0+) or Legacy Frameworks (requires Rapise 7.0+) topics.
Rapise has built-in function Navigator.DoWaitFor to wait for object to appear. If you need to do the opposite add the following function into your User.js.
In this article we will get contents of the HEAD element to get the links to all referenced stylesheets. It may be useful if you plan to verify that a set of CSS did not change for a page.
This articles describes how you can use the Navigator.CheckObjectExists(...) action to see if an element exists on a web page and how it differs from the Global.DoWaitFor / DoWaitForProperty actions that are described in another article.
Sometimes you need to synchronize the test script so that it waits for a specific application event (change for status message or wait for some specific value). This guide explains how to ensure that Rapise waits for the appropriate condition.
This article is for those who test a desktop application via UI Automation library. Since desktop applications are frequently built using UI controls from different vendors and the number of such controls available on the market is pretty big (> 1k) - Rapise may not have out-of-the-box support for some controls in your application. For such cases Rapise offers a low level API to navigate UI Automation tree of elements inside an application and read/write element properties. In this tutorial we'll show how to use this API and quickly add minimal support for a custom control.