Ranorex Blog - Software Automation & Automated Testing Blog

With the Excel Plug-In (Beta) it is now possible to automate the content of an Excel work sheet. This plug-in is not designed solely for getting data from Excel sheets (please read Data Driven Testing here), instead it offers you the opportunity to automate the cells, rows and columns of an Excel document. For example, if you want to validate the impacts of your add-on on Excel, then the Excel plug-in is definitely the correct tool for you. In addition to access to the Excel UI elements, there are also new adapters available:

• ExcelApplication
• ExcelOleObject
• ExcelRange
• ExcelShape
• ExcelWorkBook
• ExcelWorkSheet

Through these adapters it is also possible to interact with the objects provided by the Excel object model. Read more »

Depending on the technology of your application under test, your controls may have dynamic identifiers. You could of course adapt the path for each repository item, but you would have to do this every time a new item is added. The RxPathWeights plug-in enables you to filter out those identifiers and use an even better attribute to identify your application under test.

Set up your RxPathWeights configuration file (Ext-JS example)

Let’s assume we would like to automate a website which is built on the Ext JS framework (a cross-browser JavaScript library).

The picture below shows the RanoreXPath of an ext-js input field on following ext-js example page.

Read more »

There are many different possibilities for organizing a Ranorex Studio test automation project. The main goal when doing professional test automation with Ranorex is to create reusable automation modules. This can be realized by distinguishing between commonly used automation modules which perform actions like starting an application and specialized test modules performing a narrowly defined task.

The test project solution consists of:

• an executable project (command line project)
• a project related library project (.NET DLL)
• and a commonly usable project, which can be referenced by other test projects

Read more »

When you run your daily user interface tests, the key point is to review the results of the individual tests. You want to know which tests succeeded and which failed, and maybe want to be notified of the results. Additionally, you might want the style of the reports to match the corporate identity design. Ranorex provides you with a flexible and customizable reporting engine that you can adapt to fit your needs.

This blog shows you how to:

• Customize the Ranorex default XML/HTML report
• And how to add an additional reporting mechanism to the Ranorex report engine in order to get informed of test outcomes by email

Read more »

It’s the easiest way to start with test automation. For everyone. Click the ‘Record’ button, perform some mouse and keyboard actions, stop the recording, and finally replay all the recorded steps again to see how automation works. Sounds simple. But is it? When talking about capture replay with experienced test automation engineers, you almost always receive  the following advice: “Don’t touch it!” But what is reason for this?

Let me mention only a few points, which cause testers to think negatively about capture replay:

• Replay won’t work on different resolutions or window sizes because of coordinates captured within a script.
• Difficulty to maintain generated scripts.
• Impossibility to reuse recorded tests.

In short: Over the last 15 years Capture&Replay became discredited, because of not being able to maintain generated scripts after creation.

When looking at the Ranorex tools in general, it wouldn’t be necessary to provide users with Ranorex Studio around the Ranorex automation library, if the Ranorex Recorder is the all-in-one tool suitable for every automation purpose.

But how does Ranorex Recorder try to solve those issues?

The most important approach is the total separation of identification attributes and values from the automation part allow it to maintain existing recordings, without the need of editing the generated script behind. Additionally, the automatically generated code can be directly reused in hand-written test scripts (if the user wants to).

In the following section, I’d like to suggest how to best create, clean up and modify recordings, their repositories included. As an example, I’ve recorded some actions performed on the Ranorex web page. Read more »

Unexpected dialogs and pop up windows can interrupt, and in worst case break your test automation tasks. Especially when running them over night, it’s necessary to handle these dialogs automatically in order to continue test execution. Within the following article I want to point out how to click away pop up dialogs automatically using a simple thread implementation. The attached application “Dialog Simulator” is used to simulate three different types of message boxes.

By clicking the ‘Start’ button the application waits 5 seconds before showing one of the different message boxes:

Read more »

Executing test cases on several operating systems and several browsers is a major requirement for an effective UI test. To ensure that the objects are identified correctly on different browser and OS versions, it is necessary that the UI object identification is accurate. The RanoreXPath enables accurate recognition and filtering of UI elements.

The source directory of the application under test, or the web application URL for a web test, may change on test machines and servers. For that reason, it is helpful to set execution parameters before starting test scripts on the test machine. Read more »

Writing test scripts is more time consuming than maintaining already existing test scripts. One way to minimize the time needed to implement test scripts is to keep test data separated from test code. The less test data the test code contains, the more reusable it is. Another advantage of separating test data from test code is that testers – in most cases non-programmers – are able to generate and execute tests or test suits without thorough the deeper knowledge of test script implementation.

The following example describes how FitNesse and Ranorex can be combined to automate GUI testing without having static test scripts. Moreover, it gives a quick overview as to how to manage, maintain and execute test scripts using FitNesse.

Read more »

In many cases, custom Windows Forms or 3rd party provided controls are not built with accessibility in mind. It is often overlooked that by adding this functionality one does not only help those who are dependent on good accessibility, but that it also enables automation (and automated testing) of the control in question.

In the following example, I would like to show that in Windows Forms it is quite easy to add accessibility functions to an existing control, even to a rather complex control like a tree view. The control used in the example is the TreeViewAdv, a quite popular open source tree/list control. But please consider that also other complex controls like data grids or list views from other 3rd party vendors (Infragistics, DevExpress, Syncfusion, ComponentOne, Telerik, Janus, …) can be extended the same way as described within the following scenario.

Although it is quite nice to use, it lacks an accessibility implementation, rendering its content totally opaque to most automation tools. (Using Ranorex’ remote invocation capability, one can still extract data from the control, though.)

Here is an example of the control filled with some test data. You can see that in addition to a standard TreeView the TreeViewAdv can have columns as well:
Read more »

NUnit is an open source testing framework for .NET languages. It´s based on the XUnit testing design which contains powerful functionality for test execution. In this article I want to show how to make your Ranorex Tests fit for NUnit. Read more »