• What is the Problem?
• Identify Dynamic Content
• Add a Weight Rule
• Add a Condition to the Weight Rule
• Conclusion

What is the Problem

Ranorex decides which attribute will be used for object identification based on predefined attribute weights (or “RanoreXPath weights”). Usually the ID of an object will be the best and most stable attribute for identifying and object and therefore has the highest weight. But when facing dynamic IDs, the ID cannot be used to identify an element anymore because it changes each time the element is reloaded/displayed. That means that you manually have to change how the objects are identified in your repository (which might be previously created by the recorder). This blog post will illustrate how you can add so called “weight rules” (RanoreXPath weight rules) allowing you to continue using the recorder and no longer changing your repository manually afterwards.

Identify Dynamic Content

First of all we have to identify in general whether we do have a dynamic ID problem or not. Let’s have a look at yahoo.com which is based on YUI (Yahoo User Interface library), a free open source JavaScript and CSS library. This library uses dynamic IDs by default. To analyze the occurrence of dynamic contents you can use Ranorex Spy from the start menu. Use the “Track” button to analyze an element of the web page.

When you take a closer look at the attribute “Id” of the just tracked element, you will see that it contains dynamic content (yui_3_8_1_1_13679224741219_543).

That leads on the one hand to a poor readability, and on the other hand destroys the testability of the page as the element cannot be identified by its ID anymore after reloading.

To illustrate this behavior, add the analyzed element to the repository (using the context menu), reload the website and add the element again. You will see that the same element will occur twice in your repository having different RanoreXPaths based on different IDs. Highlighting the first (red) repository element will not work as an element with the given ID is not available anymore. Also, the second (blue) element will only work until you reload the page again and a new ID is generated.

So this way we identified that we do have a dynamic ID problem. (For the sake of completeness: In most of the cases the attribute “Id” leads to dynamic content issues, but of course there can be other attributes creating identification problems as well.)

Add a Weight Rule

Write down the capability and the belonging attribute.

After identifying the correct capability and its attribute, we add a path weight rule to “filter out” the dynamic content and use another property for object identification. To do so, make sure that all other Ranorex instances (Studio, Recorder, Spy, etc.) are closed and only the currently using Spy instance is open. Then open “RanoreXPath Weight Rules” editor from settings dialog and add a new weight rule by pressing the “+” button:

Choose an appropriate rule name, select the previously identified capability as well as the attribute, and set the weight to 0:

Have a look at the attribute overview (“Show Attribute Overview…”) to get a feeling for the existing attribute weights. In order to navigate to a specific capability, simply press the initial letter of the capability’s name on your keyboard.

As you can see in this dialog, the weight of the attribute “Id” is set to a value of 200. When lowering this weight to “0″ the attribute “InnerText” will be used to identify the element as it’s the next higher value of 140. If no other attribute is available (because the weight is set to zero or it has no value) the index of the element will be taken to identify it (e.g. [1]).

(For the sake of completeness: In addition to lowering the weight of attributes you don’t want to use, you can also raise an attribute’s weight to favor the use of this specific attribute for object identification.)

Add a Condition to the Weight Rule

The matching expression must start with the string “yui” followed by “_” and a number for one or more times. The whole “_” and number stuff must occur one or more times. For further details about regular expression have a look at the regular expressions wiki page or the chapter RanoreXPath in our user guide. Select the attribute you want to match against the regular expression from the dropdown, and then enter the regular expression.

Check whether the newly created rule in the left sided list is enabled, and save your changes by pressing the “OK” button.

You can check whether the newly added RanoreXPath weight rule works or not by tracking the element again on the website. You will see that the attribute “Id” is no longer used to identify the element, but by the “InnerText” attribute now.

You can best see the difference by adding the element to the repository again (green).

Conclusion

Since you created a global “path weight rule” for your object identification, the rule will also be applied if you create a repository manually (as described in the blog post “Did you know… that you can manually generate a recording?“).

Performing the following very simple adaptions, you will be able to open the report file using any common browser.

• Share via Mail
• Share Over Local Network
• Conclusion

To share a Ranorex Report you can manually compress all files necessary for reporting and attach the corresponding package to your mail. Or you can simply activate the creation of a zipped report file and attach the generated zipped report file (*.rxzlog) to your mail. These two mentioned methods require that the Ranorex Report Viewer is installed on the machine receiving the shared Report.

To overcome this requirement simply change the extension form “*.rxlog” to “*.html” in the Test Suites properties pane.

After that, you will be able to open the generated report file using any common browser as well as compress all files necessary for reporting and attach them to an email.

Next to sharing your Ranorex Reports via mail, you can also share them over your company network. You can for example use the Microsoft Internet Information Service (IIS) for doing so.

In Ranorex Studio right-click on the project you want to share the report of and choose “Open Folder in Explorer”. Right-click the “bin” folder and open the “Properties” dialog. Switch to the “Security” tab and click on “Edit” button.

Click on Add, enter “Authenticated Users” in the “Names” edit field and confirm the added permissions by pressing the “OK” button in all opened dialogs.

Define a folder in your Test Suite settings, where the report files should be stored at and change the report file extension from “*.rxlog” to “*.html”.

After doing so, add a website linking to the defined Content Directory in Internet Information Service Manager.

To correctly display your report data you have to add the extension “.data” to the list of “MIME-Types”. To do so, open the “MIME Types” settings dialog. Add a MIME Type for the file name extension “.data” with the type “application/xml”.

Enable “Directory Browsing” for displaying all generated report files on your website.

Now you are able to view your report file over the network using all common browsers.

By performing these easy to follow steps you will be able to share your Ranorex Reports to any machine regardless of a Ranorex installation or even the operating system by opening them using any common browser. You can even share Ranorex Reports to mobile devices.

• Infrastructure
• Make Your “MonoTouch” (iOS) App Testable with Ranorex
• Make Your “Mono for Android” App Testable with Ranorex
• Conclusion

MonoTouch and Mono for Android, both developed by Xamarin, are commercial implementations of Mono – a cross-platform implementation of C# – for iPhone and Android-based smartphones.

Using these two implementations it’s easy to reuse most of your existing code when porting from Android to iOS or vice versa. Next to that it’s possible to import existing .NET libraries and to use them in your Android/iOS apps.

Ranorex supports test automation for both, Mono Touch and Mono for Android. Simply follow the steps below to make your cross-platform app testable.

To instrument your MonoTouch app you simply have to add the Ranorex automation library for iOS  to your MonoTouch project as native library.

To instrument your Mono for Android app simply follow the step by step instructions below.

• Add the Ranorex automation library for Android (<RanorexInstallDir>\bin\RxEnv\Android\Ranorex.jar) to your Mono for Android project.
  
  
  
• Open the properties of the added file and set the build action to “AndroidJavaLibrary”.
  
  
• Download the file RanorexAndroidMonoInstrumentation.cs and add it to your project (the same way as described in the first step).
• Add the following lines of code to each activity in your project:

  public override bool DispatchKeyEvent (KeyEvent e)
  {
    Ranorex.RanorexAndroidMonoInstrumentation.dispatchKeyEvent(e);
    return base.DispatchKeyEvent (e);
  }
  
  protected override void OnResume ()
  {
    base.OnResume ();
    Ranorex.RanorexAndroidMonoInstrumentation.onResume(this);
  }
  
  protected override void OnPause ()
  {
    base.OnPause ();
    Ranorex.RanorexAndroidMonoInstrumentation.onPause(this);
  }

• Open the properties of your project and add a new “Android Manifest” in the “Mono for Android Application” area.
  
• Add “(RxInstrumented$4.x.x)” to the version name (whereas 4.x.x is the Ranorex version you are using) and activate the check boxes “INJECT_EVENTS” and “INTERNET” in the “Required permission” area.
  

Following these simple step by step instructions will make your MonoTouch and Mono for Android apps accessible for Ranorex and nothing should be standing between you and your robust cross-platform test automation.

To get started with mobile test automation, have a look at the chapters “Android Testing” and “iOS Testing” in our user guide.

• Infrastructure
• Version Control System
• Bamboo Server
• Build Agent
• Add a new Plan
• Version Control Settings
• Configure Tasks
• Configure Artifacts
• Configure Notifications
• Run Job
• Conclusion

A developer or test engineer commits his changes to the version control system. Based on the committed change, the version control system triggers the continuous integration system to start a job which triggers the build agent to

• check out the modified source from the version control system,
• build the application under test (AUT),
• build the Ranorex Test Suite and
• execute the Ranorex Test Suite which tests the AUT.

The corresponding Ranorex Report file as well as a build log will be attached to the build iteration.
The developer and/or test engineer responsible for the changes will be notified about the build and test success.

To start the application under test from your test project, simply add a new ‘Run Application’ action to your recorder action table which starts the application under test using a relative path from the bin folder of the testing application.

Download the Bamboo installation package and follow the installation instructions.
A download link and further information about Bamboo can be found on the Atlassian homepage.

If you are going to use the default build agent running locally on the server, make sure to not start the Bamboo Server as service, but to start the server in a console as you can see in following figure. The reason is that a service does not have sufficient rights to start and access UI applications.

After starting the server in a console, you can access the web interface of your server from the address shown in the console window (e.g. localhost:8085).

Follow the instructions of the Setup Wizard to configure your CI server.

To allow your CI process to notify the responsible developers and testers about a build success, configure your mail server (Administration -> Communication -> Mail Server).

The default installation of the Bamboo Server includes a build agent running on the local machine. You can scale out your build infrastructure on multiple machines by installing several remote build agents using following instructions: Bamboo Remote Agent Installation Guide

Note: Make sure that a valid Ranorex license as well as the Ranorex main components are installed on every Build Agent you are going to build/execute Ranorex automation code.

Choose a project the plan will be added to and a plan name.

Add a MSBuild task for building the testing application by choosing the solution file (*.sln) of the Ranorex Automation project relatively to the SVN working copy root.

Add a command task which starts the Ranorex Test Suite executable.

As you can see, we defined a set of command line arguments.

In this sample the command parameter ‘/zr’, which triggers the test suite executable to generate a zipped report file and ‘/zrf:.\Reports\Report.rxzlog’ which defines the name and the location of the generated zipped report file, as well as the command parameter ‘tc:/TestCase’ which specifies the test case to be executed are used. The location of the report file will later be used to define the build artifacts.

You can find a list of all available command line arguments in the section ‘Running Tests without Ranorex Studio‘ in our user guide.

The test suite executable returns ’0′ on success and ‘-1′ on a failure which allows the test agent to either mark this build step as successfully or failed.

After defining the tasks, the newly added plan can be enabled and created.

This will trigger an initial build.

In the plan’s configuration choose the default job and the ‘Artifacts’ tab and click on the ‘Create Definition’ button.

Choose a name for your definition and define the path where the Report files will be stored, relatively to the SVN working copy root (e.g. ./TestCIProject/TestCIProject/bin/Debug/Reports/). If you want to attach all files in that path to your build, you can use the copy pattern ‘*.*’. Otherwise you have to use a more specific copy pattern like ‘*.rxzlog’ which would only copy zipped report files.

You can investigate the attached Report file of a specific build by opening the ‘Artifacts’ tab of the build and clicking the Report file.

Agile development processes are implemented using continuous integration tools. To keep individual iterations speedy, it’s absolutely essential to bring automated testing into the continuous integration process… and likewise into the agile development process.

Ranorex can easily be integrated into continuous integration systems as Ranorex Studio creates an executable from of its Test Suite projects that can be triggered by almost any CI system.

This blog post explains how to integrate Ranorex automation into your existing continuous integration process.

• How it should work
• A closer look at the CI System
• Build Application Under Test
• Build Ranorex Test Suite
• Execute Ranorex Test Suite
• Provide Feedback
• Blog posts concerning integration into specific systems
• Conclusion

Note: It is necessary to have the Ranorex main components – and a valid Ranorex license – installed on each machine on which you are going to build and execute Ranorex code.

The whole build process will be triggered by committing changes to the version control system. For this reason the source repository as well as a mechanism for checking for changes (e.g. a checking interval) in the repository has to be configured.

After checking out the committed code from your version control system three steps in your build process have to be added.
One for building the application under test, one for building the Ranorex automation project and one for executing the Ranorex automation project.

With frequently applying code changes, it does not make sense to run the whole test suite with all it’s test cases but a subset of test cases regarding the affected area. For this reason, you can use so called run configurations which can be added and edited directly in the test suite editor (as you can see in the section ‘Running a Test Suite’ in our user guide).
The following example will illustrate how a run configuration can be triggered using command line arguments:

Executing following command line will run the test suite executable called ‘TestCIProject’, run the run configuration called ‘SmokeTest’ and generate a zipped report file called ‘Report.rxzlog’ stored in a folder called ‘/Reports/’:

TestCIProject.exe /rc:SmokeTest /zr /zrf:Reports/Report.rxzlog

You can find a list of all available command line arguments in the section ‘Running Tests without Ranorex Studio‘ in our user guide.

• Bamboo CI with Ranorex Test Automation
• Integrating Ranorex Automation in TeamCity CI Process
• Integrating Ranorex Automation in Jenkins CI Process
• Running Ranorex Automated Tests with HP Quality Center
• Running Ranorex Automated Tests with Microsoft Test Manager

Conclusion

As you can see, it’s easy to integrate Ranorex Automation in any system, simply by triggering the system to execute the Ranorex executable.
Please feel free to share your thoughts on this topic in the comments section.

]]>