It is common for test scenarios to share similar pieces of functionality. A good example of such sharing is login logic. This guide outlines ways in which you can share such logic to avoid having repeated code in your tests.
This article is obsolete. To find out about re-using test parts, modules and page objects please refer to Rapise 8.0: how to use Page Objects/Modules.
Many web sites use HTML tables to display lists of tabular data. When testing such applications you will often need to dynamically search for items in the table to verify that the application under test performed correctly. This guide outlines best practices for accessing data held in HTML tables.
This article is obsolete. For dealing with dynamic table data please refer to How to define and use a dynamic Web locator article.
Yes, in general, Rapise can automate most web applications using mobile Safari running on iOS (either on a real or simulated device). However there are some limitations.
This article is obsolete. The recommended way of testing Web applications is to record tests on a desktop browser via Selenium-based profile and then execute using Mobile profiles. See How to run a cross-browser test on a mobile device for more details.
In some cases it is convenient to store tests in the same Git repository where source code of an application under test is located. For example, if you are using Visual Studio Team Services. From this article you will learn how to execute Rapise tests stored in a Git repository with SpiraTeam and leverage the power of SpiraTeam reporting and analysis features.
This article is obsolete. There is much simpler approach with use of RapiseLauncher Extension for Azure DevOps.
The notion of the integrated test framework usually implies common functions and shared data between tests. Here we provide sample configuration making sharing Spira-friendly.
This article is obsolete. If you are on Rapise 8.0+ then we recommend to follow the new Framework Mode methodology and start with the Benefits of using the new Framework mode KB article.
Sometimes when testing certain web applications instead of the browser DOM tree appearing you will see strange results such as "Node0" appearing. This is caused by the application using nested frames with potentially different security origins. This article describes some of the common issues and describes the solution.
We have had a couple of questions about whether Rapise can test Adobe AIR based applications running on mobile devices using platforms such as Android. This article provides some background and also describes the support Rapise has.
[We have depreciated support for testing Adobe Flex/Flash applications in Rapise 5.0 and later, so this article is provided for use by existing customers]
Rapise 4.0 supports the testing of Adobe AIR Flex applications using the Adobe Integrated Runtime (AIR). Rapise can test applications using a wide variety of different Flex controls and supports testing both Flex 3 and Flex 4 applications.Rapise 4.0 supports the testing of Adobe Flex applications that are executed by the Adobe Flash Player inside the Internet Explorer, Mozilla Firefox or Google Chrome web browsers. Rapise can test applications using a wide variety of different Flex controls and supports testing both Flex 3 and Flex 4 applications.[We have depreciated support for testing Adobe Flex/Flash applications in Rapise 5.0 and later, so this article is provided for use by existing customers]
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.
In Rapise 2.2, "DoClick" behavior was changed, so we don't do a click but rather just position the mouse over the control and do API-level "click" event. However we provided a way to enable backward compatibility.
This article is obsolete.
A Flex application requires some instrumentation to be ready for testing. By default Flash player has security restrictions preventing Rapise from accessing the application contents. Please, check the this help topic to learn more about Adobe Flex testing.
This article is obsolete. Flex support was removed from Rapise.
When executing Rapise scripts from SpiraTest using RapiseLauncher there is a 10-minute inactivity timeout. If your scripts have periods of inactivity that last longer than 10 minutes, you may need to extend the default timeout. This article describes the steps for doing this.
This article is obsolete. Since Rapise 5 there is no default timeout anymore.
When using Rapise, it is often useful to see how Rapise is identifying objects in the Application Under Test (AUT) and if necessary find out why Rapise is not able to locate a specific object. This article outlines how to increase the logging level in Rapise.
This article is obsolete. There is no ribbon in Rapise since version 6. If you have Rapise 6.0+ then follow these steps to change the verbose level.
By default the Rapise Flex library supports a wide variety of Flex controls which will be capable of testing the majority of application. However sometimes there will be an unknown objects which will be learnt as a generic object with FlexObject flavor. The article describes support for such custom Flex controls.
This article is obsolete. Flex support was removed from Rapise since Flex is dead already for a long time.
When writing a web test in Rapise you will often want to run the same test script in all three web browsers (IE, Firefox and Chrome). You will want to be able to choose the Test Script from within Rapise when debugging the test and then from a Test Set in SpiraTest when you move the test into production. This article explains the process.
This article is obsolete. For modern way of running Rapise tests in multiple browsers please refer to Rapise 8.0: how to run test cases on different browsers.
Sometimes you will have controls in a WPF or Silverlight application which use dynamic lists. Depending on certain settings, the widgets in the list will appear in different places. This means that a learned Rapise object which works fine if its in the original ListBox[0] location position is not found during playback when it's displayed in another position, e.g. ListBox[1] or [2].
Unlike the XPath option with web testing, Rapise doesn't currently allow regular expressions (Regex) in locators stored inside the Objects.js file. This article describes a way around the problem.
This article is obsolete. Rapise supports regular expressions in UIAutomation locators since version 6. Read this article for more details.
Often you want to be able to parameterize your Rapise tests to have a common set of test functions that can use different combinations of test data. You can use a MS-Excel spreadsheet to store the test data and use Rapise to read out the matching values. This articles provides a sample for doing this.
This article is obsolete. For modern ways of making data-driven tests please refer to Data-Driven Testing documentation topic.
When running a test you will often want to make sure there are no other browser windows open. This is commonly done either at the start or end of the test. This article describes how you do this.
This article is obsolete. With Selenium-based connectors (default option since Rapise 7.3) opened browser windows are longer an issue. One may continue to use regular browsers. Rapise will use isolated browser profiles to run tests.
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.