For some time I’ve wanted to share an idiom I personally use and recommend when building Selenium Tests. This idiom allows to control which browsers are used to run the tests without needing to update test sources or configuration.
The simple ideas behind this idiom are:
- Test code and configuration should not depend on the test environment.
- Tests can be executed in any given browser, independently from others.
- To change the browsers used for test execution, it is not needed to update test sources or configuration.
- Selenium Grid URL and application URL are also configurable.
- Both environment variables and Java system variables can be used.
- All settings have sensible defaults.
I call this idiom ‘Browser-Selectable Tests’. I promise I keep thinking on a better name 🙂
Continue reading “Idiom for Browser-Selectable Selenium Tests”
For some time I’ve been willing to record and upload a short video showing how Selenium works, working in a grid with several computers/browsers and an Android table as well.
For this short demo I’ve used the Spring PetClinic reference application, tweaked to work with Spring 3.0.6 and Tomcat 7.0.22.
This short video is slightly above one minute long. Hope you enjoy it!
Yes, it’s true. With Selenium you can automate UI tests for Android browsers.
Validating how a web application behaves in multiple browsers is a growing need, as users require using any browser of their choice to consume applications. Moreover, this need spans to mobile devices: applications are demanded to be ubiquituous, and so our tests should be.
To my (pleasant) surprise, it’s very easy to run automated tests in Android browsers. Selenium includes an Android driver that supports most of the Android browsers, both simulated and in physical devices.
Continue reading to know more.
Continue reading “Using Selenium to Automate Tests in Android Browser”
In part 1 in the series (read it here) I discussed about Selenium, the widely used tool for browser test automation, and I showed how easy is to setup a testing grid with multiple OS and browsers. In part 2 (read it here) I showed how to leverage WebDriver API to create and execute tests distributed across the grid that was created.
Now in part 3 I will show how to execute Selenium tests under a Continuous Integration process with Maven, Cargo and Jenkins, and how to gather code coverage metrics for those tests using Sonar and JaCoCo.
Continue reading “Test Automation with Selenium WebDriver and Selenium Grid – part 3: Continuous Integration”
In part 1 in the series (read it here) I presented Selenium, a widely known tool for browser test automation.
Starting with Selenium 2, the most important components from the suite are Selenium WebDriver and Selenium Grid. In part 1 I showed how easy is to setup a testing grid with multiple OS and browsers. Now in part 2 I will show how to leverage WebDriver API to create and execute tests.
Continue reading “Test Automation with Selenium WebDriver and Selenium Grid – part 2: Creating and Executing Tests”
For a long while I’ve been “dying to play” with Selenium (www.seleniumhq.org and code.google.com/p/selenium/). I’ve heard and read very good things about this tool from colleagues and from the blogosphere.
Selenium is, in short, an open source tool to automate web browser interactions. A primary use case is, of course, browser test automation.
Selenium has greatly evolved with time, specially since the 2.0 release when the legacy Selenium project merged with Google’s WebDriver. Nowadays, Selenium offers a wide range of programming languages supported to write the tests, an impressive browser compatibility list, the ability to record tests from user interactions and, above it all in my opinion, the ability to re-execute tests across a grid of machines with various operating systems, browser families and versions.
Although Selenium seems to be primarily chosen for functional/regression test automation, it’s also a great choice – precisely because of the grid feature – for cross-browser compatibility testing: ensuring in an easy, cost-effective way, that our web applications are usable in all sorts of operating systems and browsers.
In this and forthcoming posts in a short series I will share my experiences setting up a Selenium Grid, building some automated tests for a simple Spring application, re-executing them from Eclipse IDE and finally re-executing them in continuous integration (including code coverage) with Maven, Cargo, Jenkins, Sonar and JaCoCo.
Continue reading “Test Automation with Selenium WebDriver and Selenium Grid – part 1: Setting Up the Grid”