Testing is a crucial part of the software creation process. It ensures that your code is working correctly and that all bugs are found before the software lands in the hands of consumers. But it can be difficult to explain these tests and their results to investors...
We’ve introduced a ton new web testing features in Ranorex 7.1, which come in particularly handy if you’re a Selenium user: not only did we speed up our Selenium WebDriver integration, but we’ve also introduced some new concepts that are sure to ease your web testing efforts.
In this blog, I’d like to give you a quick overview of the currently available web testing approaches, before explaining the changes we’ve made to the test environment. Stick with me – I can assure you that in under 15 minutes, you’ll have gained a comprehensive understanding of web testing concepts in Ranorex 7.1.
Ways to Test Your Web Application in Ranorex 7.1
When running a Ranorex test suite, there are multiple ways of interacting with the browser, depending on your application under test (AUT), configuration and needs. Do you want to utilize Selenium WebDriver on a grid? Check. Do you prefer to test the desktop environment with UI elements outside the HTML DOM? Check. Do you want to scale up your web tests and save time by running them in different environments at the same time? We’ve got you covered.
All this functionality comes with somewhat of a complexity. In a first step, you need to define the actual requirements of your test suite. Selenium WebDriver enables you to rely on standardized methods for web automation, whereas the plugin-powered Ranorex web automation is more powerful when you want to reach outside the DOM of your web application, or test multiple applications at the same time. To get a comprehensive understanding of the available web testing approaches and their individual capabilities, have a look at the table below:
|Ranorex Web Automation||Selenium WebDriver Integration in Ranorex Studio|
|Test web applications (i.e. interact with the page’s DOM)||✓||✓|
|Plugin-free web testing in native browser||✓|
|Multi-platform (Windows, macOS, Linux)||✓|
|Test operations outside DOM (e.g. open file dialogs, print, etc.)||✓|
|Cross-application and/or platform testing||✓||✓*|
|Execute web tests in parallel||✓**||✓***|
|Integrate in CI environments as a post-build step||✓||✓|
|Record in browser||✓|
|Test on mobile devices||✓||✓|
* The current automation root can be switched in user code, works only on locally-running WebDriver hosts ** By using Ranorex Remote *** By utilizing a Selenium Grid
Thanks to the efforts of our development team, and our keen eye on compatibility to previous Ranorex versions, the separation is not that strict. Every Ranorex test utilizing Selenium WebDriver can also be executed using the Ranorex web automation framework.
So you’ve decided which web testing approach to take in Ranorex Studio. But how do you set up the environment? What has changed in Ranorex 7.1? Let’s take a closer look.
Endpoints in Ranorex Studio
Historically, platform-specific information, such as which browser the test should run in, was located in the recording. In order to run your tests in different environments, you had to edit the test suite itself, which increased maintenance overhead. That’s why in Ranorex 7.0, we’ve started to separate test suites from the environment they are eventually going to run in. As you can see in the graphic below, the runtime information is no longer connected to the test information itself.
The benefit? Design once – run everywhere. One test suite can now serve multiple purposes, and there’s no need for data binding in order to set-up different environments. Simply configure endpoints in Ranorex Studio and pass them as arguments to your test executable. This also allows you to run the same test suite multiple times in parallel, omitting the need to wait as multiple target machines can be automated at the same time.
In Ranorex 7.1, we’ve refined this concept even further: Endpoints now support the definition of individual configurations. A configuration is a set of capabilities for the WebDriver in JSON format. When using configurations, you can define multiple scenarios for test automation for each endpoint. This is particularly useful when working with Selenium Grids, as you only have to add your WebDriver Hub once and can define different behaviors for it.
Selenium Nodes and Grids
Ranorex Studio supports Selenium nodes and grids as endpoint nodes. A Selenium node is a Selenium server application that runs in a specific target environment, such as Windows, and controls a single browser instance at a given time through its WebDriver. Selenium Grids unify and manage a number of nodes through a single hub. By dispatching tests to the next available Selenium server, Selenium Grids enable parallelization.
In Ranorex Studio, you can also register cloud-based grid providers as endpoints. Using cloud-based Selenium Grid implementations, such as Saucelabs or Selenium Box, you don’t even have to set up your own infrastructure and can immediately run your tests in parallel, against different browsers and browser versions.
You can define the environment of your web tests with the help of capabilities. Capabilities specify exactly which operating system, browser or browser version your test will run in, and much more! There’s a wide range of capabilities you can choose from – simply check out Selenium’s documentation.
In Ranorex 7.1, we’ve extended the endpoint concept with endpoint configurations. A configuration is a set of capabilities in JSON format, which you can pass to the WebDriver endpoint, to specify additional environment information. An endpoint can have a set of configurations.
You can define them freely on your own, or use our capabilities configurator to generate your preferred configuration with the most common settings.
Don’t like to type in JSON? Neither do we.
Utilizing Endpoint Configurations
After defining at least one configuration for any endpoint, they can be used in your test suite for execution. You can also set a default configuration for an endpoint in Ranorex Studio. This default configuration specifies the set of capabilities that will be used when you select the endpoint at runtime.
Additionally, you can activate an endpoint configuration from command line with the /epc parameter. This configuration will be used for the selected endpoint during test execution. If you are working with Selenium Grids, you can execute multiple Ranorex test suites on an endpoint at the same time, using different endpoint configurations.
Recording Data vs Endpoint Configurations
Next to endpoint configurations, it is still possible to define the web browser and other settings in a Ranorex recording as well. This data is used mainly as a fallback when executing the test without an endpoint provided. If you select an endpoint but no endpoint configuration, the recording information is taken instead as well.
Endpoint configurations are treated with higher priority and, therefore, the active configuration will launch instead of Firefox.
Selecting an endpoint and configuration (via command line parameter or as automation root in Ranorex studio) always overrides the recording values, if they are specified accordingly.
How Ranorex Executes Web Tests
The way a Ranorex web test behaves, depends on the way it is started. Double-clicking the test executable runs the test on the local machine utilizing the Ranorex web automation, regardless of any endpoints you have defined. Additionally, Ranorex Studio creates shortcuts to the test executable for all the endpoints configured. By clicking on a shortcut, the test is executed locally, but the automation retrieves necessary data over the network from the endpoint.
You can also specify which endpoint should be used as automation root during test automation from command line with the /ep parameter. As endpoints are saved in the solution settings, they are accessible from any location your test executable is deployed to. Imagine having a set of endpoints and configurations in your solution settings file. Executing your test on multiple endpoints is super easy by just creating a Windows batch file and either looping through them or even starting them in parallel.
Additionally, you can easily integrate your Ranorex tests in CI environments. By adding a Ranorex test as a post-build step, you can instantly verify the quality of each build by testing your website – in multiple environments at the same time. That’s how you get faster feedback and better results by defining endpoints and endpoint configurations!
Ready to scale up web testing? Save time by executing WebDriver tests in parallel with the new tool we have in the works. Using this tool, you will be able to specify endpoint configurations in a matrix and run a test suite in parallel. Stay tuned and register for our beta program to be among the first to try it out!
Gherkin: Overview, Use Cases, and Format
Gherkin is a format used for cucumber testing. In this article, we go over what it is, its use cases, and the format of Gherkin.
The Importance of SQL Injection Testing
SQL injection testing is important for finding vulnerabilities and keeping your information secure. Learn more here.
6 Best Practices for Code Review
Code review is a daunting process, but there are ways to make it easier, more efficient, and more accurate. Learn more here.