Ranorex Studio does a great job of hiding all the internals making things simple for non-coders. When you get started with Ranorex, recording modules and building test suites, you don’t have to know too much about how it does things internally. But as your test suites grow and become more complex, knowing a bit more about how things actually work can help improve your tests. You’ll be able to optimize your modules and repositories, increase module reuse and improve test run performance.
Overview
Ranorex has three basic interacting pieces: plugins, elements and adapters. Almost everything else boils down to these. Whether you’re programming directly against the API or designing your test suites with Ranorex Studio, these are the pieces that make your tests work. Understanding these three might not give you any immediate insights that will improve your tests, but it will put everything else in perspective.
RanoreXPaths and repositories put these pieces together in different ways and provide much more advanced functionality. Besides making it easier to find elements and work with them, optimizing RanoreXPaths and repositories can significantly improve your tests.
This post briefly cover plugins, elements and adapters. RanoreXPaths and repositories are covered separately.
Plugins
Plugins tell Ranorex how to work with different UI platforms and technologies. A plugin does a few things, but its most important role is to map platform-specific controls to Ranorex elements. It knows how to respond to changes in the UI and activate the controls.
Ranorex supports quite a few platforms. You can find the platforms in any test suite project’s References folder. There are plugins for:
- Microsoft’s WPF, WinForms and Win32 platforms;
- the Internet Explorer, Chrome and Mozilla browsers;
- the cross-platform Java and Flash/Flex UI platforms;
- the Microsoft Office and SAP applications;
- the Mobile Android, iOS and Windows Phone platforms;
- a few other assorted technologies.
Ranorex continues to add plugins that add or improve support for existing and emerging platforms, some of which are provided out of the box and others, such as the LabVIEW plugin, are purchased separately.
Elements
Elements store metadata about UI controls and provide the information Ranorex needs to find and work with them. They also provides a few basic functions that every UI control has to support, such as determining whether a control is visible, providing its size and coordinates on the screen, and calculating paths for any element. Elements capture screenshots and snapshots, determine element hierarchy and support query operations and other features. Elements also use caching to improve performance, though this support is only really configurable when coding against the Ranorex API and managed automatically by tests built in Ranorex Studio.
When you look at an element in the Spy, the Overview and Detail tabs shows attributes and properties split into various sections. The attributes in the General section are common to all elements and their values are provided by the element directly.
Coders using the Ranorex API will often use the Element class to find elements and read their metadata. But elements are rather abstract and difficult for non-coders to use, so Ranorex Studio uses repositories instead. Repositories are covered in the next post.
Adapters
Adapters represent the behavior shared by similar controls, regardless of the UI technology, and make that behavior available for automation. They expose control data as attributes, and their functionality as actions. And they know which attributes and actions different types of controls are expected to have.
Every element supports multiple adapters, depending on the UI platform and the control’s capabilities. For example, the WPF platform supports the UIA technology that provides automation and accessibility support. So almost all WPF elements can be used with the core adapters (e.g., Button, CheckBox, Menu, Form, etc.) as well as the UIAutomation and related adapters.
And because they’re cross-platform, similar controls in different platforms are expected to share behavior and can use the same adapter. Plugins are responsible for applying the cross-platform behavior to each supported underlying UI platform. All buttons, for example, whether HTML button elements or WPF button controls, are represented by the Button adapter.
Different adapters are cross-platform to different extents – some more than others. For example, the Button adapter can be used to represent buttons in almost all platforms, whether Web, or WPF, or Java. In contrast, the ATag adapter represents the HTML anchor (a) tag in the various Web plugins, and is therefore only supported by the Internet Explorer, Mozilla and Chrome plugins. Similarly, there are adapters for buttons, menus, containers, windows, radio buttons, tables, tooltips, sliders, and most every other type of control, some shared by the majority of plugins and some specific to just one or two plugins.
Summary
To sum things up, elements represent UI controls, adapters provide cross-platform type-specific attributes and actions for elements, and plugins map UI controls to Ranorex elements and bind them to adapters.
In the next post, we’ll make use of this information to understand RanoreXPaths and repositories, and then we’ll start thinking about how we can optimize them.
