Articles Tagged 'object'

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

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.

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).

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.

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?