Now you can test your Mobile Web Apps with WebDriver

Mobile testing has come a long way since the days when testing mobile web applications was mostly manual and took days to complete. Selenium WebDriver is a browser automation tool that provides an elegant way of testing web applications. WebDriver makes it easy to write automated tests that ensure your site works correctly when viewed from an Android or iOS browser.

For those of you new to WebDriver, here are a few basics about how it helps you test your web application. WebDriver tests are end-to-end tests that exercise a web application just like a real user would. There is a comprehensive user guide on the Selenium site that covers the core APIs.

Now let’s talk about mobile! WebDriver provides a touch API that allows the test to interact with the web page through finger taps, flicks, finger scrolls, and long presses. It can rotate the display and provides a friendly API to interact with HTML5 features such as local storage, session storage and application cache. Mobile WebDrivers use the remote WebDriver server, following a client/server architecture. The client piece consists of the test code, while the server piece is the application that is installed on the device.

Get Started


WebDriver for Android and iPhone can be installed following these instructions. Once you’ve done that, you will be ready to write tests. Let’s start with a basic example using www.google.com to give you a taste of what’s possible.

The test below opens www.google.com on Android and issues a query for “weather in san francisco”. The test will verify that Google returns search results and that the first result returned is giving the weather in San Francisco.

public void testGoogleCanGiveWeatherResults() {
// Create a WebDriver instance with the activity in which we want the test to run.
WebDriver driver = new AndroidDriver(getActivity());
// Let’s open a web page
driver.get(“http://www.google.com”);

// Lookup for the search box by its name
WebElement searchBox = driver.findElement(By.name(“q”));

// Enter a search query and submit
searchBox.sendKeys(“weather in san francisco”);
searchBox.submit();

// Making sure that Google shows 11 results
WebElement resultSection = driver.findElement(By.id(“ires”));
List searchResults = resultSection.findElements(By.tagName(“li”));
assertEquals(11, searchResults.size());

// Let’s ensure that the first result shown is the weather widget
WebElement weatherWidget = searchResults.get(0);
assertTrue(weatherWidget.getText().contains(“Weather for San Francisco, CA”));
}

Now let’s see our test in action! When you launch your test through your favorite IDE or using the command line, WebDriver will bring up a WebView in the foreground allowing you to see your web application as the test code is executing. You will see www.google.com loading, and the search query being typed in the search box.


We mentioned above that the WebDriver supports creating advanced gestures to interact with the device. Let’s use WebDriver to throw an image across the screen by flicking horizontally, and ensure that the next image in the gallery is displayed.

WebElement toFlick = driver.findElement(By.id(“image”));
// 400 pixels left at normal speed
Action flick = getBuilder(driver).flick(toFlick, 0, -400, FlickAction.SPEED_NORMAL)
.build();
flick.perform();
WebElement secondImage = driver.findElement(“secondImage”);
assertTrue(secondImage.isDisplayed());

Next, let’s rotate the screen and ensure that the image displayed on screen is resized.


assertEquals(landscapeSize, secondImage.getSize())
((Rotatable) driver).rotate(ScreenOrientation.PORTRAIT);
assertEquals(portraitSize, secondImage.getSize());

Let’s take a look at the local storage on the device, and ensure that the web application has set some key/value pairs.


// Get a handle on the local storage object
LocalStorage local = ((WebStorage) driver).getLocalStorage();
// Ensure that the key “name” is mapped
assertEquals(“testUser”, local.getItem(“name”));

What if your test reveals a bug? You can easily take a screenshot for help in future debugging:


File tempFile = ((TakesScreenshot) driver).getScreenshotAs(OutputType.FILE);

High Level Architecture

WebDriver has two main components: the server and the tests themselves. The server is an application that runs on the phone, tablet, emulator, or simulator and listens for incoming requests. It runs the tests against a WebView (the rendering component of mobile Android and iOS) configured like the browsers. Your tests run on the client side, and can be written in any languages supported by WebDriver, including Java and Python. The WebDriver tests communicate with the server by sending RESTful JSON requests over HTTP. The tests and server pieces don’t have to be on the same physical machine, although they can be. For Android you can also run the tests using the Android test framework instead of the remote WebDriver server.

Infrastructure Setup

At Google, we have wired WebDriver tests to our cloud infrastructure allowing those tests to run at scale and making it possible to have them run in our continuous integration system. External developers can run their mobile tests either on emulators/simulators or real devices for Android and iOS phones and tablets.
Android emulators can run on most OSes because they are virtualized, so we run them on our generic cloud setup. Though there are many advantages to using Android emulators because they emulate a complete virtual device (including the virtual CPU, MMU, and hardware devices), it makes the test environment slower. You can speed up the tests by disabling animations, audio, skins, or even by running in the emulator headless mode. To do so, start the emulator with the options –no-boot-anim, –no-audio, –noskin, and –no-window. If you would like your tests to run even faster, start the emulator from a previously created snapshot image. That reduces the emulator startup time from 2 minutes to less than 2 seconds!
iOS simulators can’t be virtualized and hence need to run on Mac machines. However, because iOS simulators don’t try to emulate the virtual device or CPU at all, they can run as applications at “full speed,” this allows the test to run much faster.
Stay tuned for more mobile feature in Selenium WebDriver, and updates on the Selenium blog.

Mobile search- Mo-mentum

Mobile search helps people find what they need in a snap. Whether they’re choosing between two restaurants, shopping for a new watch, or buying a movie ticket, people make better decisions when they have access to more information. Search ads are information—answers—and on mobile devices, they’re able to connect people and businesses in new, useful and relevant ways.

Today, we’re unveiling new mobile search ad formats and some new details about the ways many different businesses are benefiting from mobile advertising.

Search ads, meet mobile apps

We’re bringing the worlds of search and apps together with mobile advertising in a few ways:

  • Search ads in mobile apps: Lots of mobile apps give people the ability to search for information—like an app that lets you search for a restaurant nearby. Today we’re announcing Custom Search Ads for these apps. These ads provide useful and relevant answers, for people searching within a mobile app. Custom Search Ads will also help app developers earn more money to fund their apps and grow their businesses on mobile.

    Custom Search Ads in mobile apps

  • Click to Download: Not surprisingly, many people use Google to search for information about mobile apps. This ad format helps consumers right when they’re searching for information about an app, linking them directly to the App Store or Android Marketplace to download. We’ve recently enabled app developers to include app icons and information about the app in their ad unit so that people can make more informed decisions about whether they want to download the app.
  • Mobile App Extensions: This new, beta ad unit enables businesses to use mobile search ads to direct someone to a page within a mobile app already installed on their phone. For example, if someone searches for sneakers on a mobile device, they might see an ad that takes them directly into a cool shopping app they’ve installed on their phone.

Local search ads—so hot right now

Building local context into mobile ads makes them more useful both for both consumers and businesses. Here are a few specific examples:

  • Click to Call: We introduced these ads for high-end smartphones less than two years ago and they’re now driving millions of calls per week to hundreds of thousands of businesses around the world. Click to call ads have been very effective in generating leads for businesses of all sizes, across many verticals—more people can call an Enterprise Rent-A-Car near them for rentals and more potential customers can connect with ADT Security for alarm system expertise, for example.
  • Hyperlocal search ads: Launched a year ago, these search ads contain useful local information like phone numbers, driving directions, a number to click and call a business directly, and also show people how far they are from specific business locations. Roy’s Restaurants’ efforts with this format led to a 40 percent increase in call volume—and lots more full tables!
  • Proximity as a factor in mobile search ads ranking: The distance between a person and an advertiser’s business location is now a factor in mobile search ads ranking. This means an ad for a business with a physical location close to to a consumer may perform better in AdWords—driving more mobile traffic at a lower cost. The feature will be effective only when consumers opt in to share their device location for mobile searches. It will make our hyperlocal format more useful for businesses and users—advertisers can get started with this by creating Location Extensions for their mobile campaigns. Particularly this holiday season, when consumers are using their mobile phones to find a nearby store for last minute gift purchases, this new feature will help connect customers with storefronts.
  • Circulars: We began testing this new ad format with Best Buy and Macy’s earlier this month. When someone clicks on a search or display ad (on desktop, mobile or tablet devices), they may see these engaging ads which contain photos of relevant products and special offers. With a few simple clicks, people who are at their desk can email that circular to their mobile phones, and later walk into their local store, flash their phone and redeem the offers.
Macy’s Circular ads on mobile

The exciting thing for mobile users and businesses is that the possibilities for mobile search advertising are nearly endless. We’re looking forward to helping businesses and consumers alike take advantage of this brave new (mobile) world.

Google Summer of Code: Write code and save lives with OpenMRS

Earlier this year OpenMRS participated in Google Summer of Code, a worldwide program organized by Google’s Open Source Programs Office to expose university students to the world of free and open source software, and encourage those students to become long-term contributors to projects that interest them. OpenMRS is a web-based medical record system originally designed for use in the developing world, and is now used on every continent on the globe. OpenMRS is used in all kinds of health care environments, from research laboratories to hospitals to small clinics in remote villages, and even via mobile devices that collect data door-to-door.
OpenMRS has been participating in Google Summer of Code every year since 2007, and our 5th year was arguably our most successful yet. This year, 15 motivated students successfully completed projects to focus or extend the OpenMRS health care IT platform in ways that will have significant impact for our global community of users. Throughout the summer our students became full contributors in good standing in the OpenMRS community. They presented their projects’ work in progress to other developers and users and often contributed their code to our software releases to support health care professionals saving lives around the world. Unlike many other summer internships that students may have during the summer, our students were responsible for planning and delivery of “real-life projects” that came from needs and requests from people installing and using OpenMRS.
Some projects were dedicated to improving the core OpenMRS platform, and some built add-on modules to support specific types of clinical activities. There were projects focused on making the installation of OpenMRS easier, and others focused on helping improve collaboration for our volunteer community. And if the presentations our students made this semester were any indication, all of the projects were exciting ways to write code and save lives. There’s not space here to describe each project in detail, but we encourage you to check out our students and their projects on the OpenMRS Wiki and learn more about them:
  • Balachandiran Ajanthan created an add-on module to deploy reusable “SMART” health care apps inside OpenMRS.
  • Christopher Zakian reimagined a “universal” search within OpenMRS that allows users to search for any system data from anywhere within the system
  • Gaurav Paliwal created an add-on module to allow OpenMRS users to provide application feedback to their system administrators and the larger open source community.
  • Gauthami Pingili improved both the UI of the OpenMRS Patient Matching module and improved its accuracy of finding duplicate patients.
  • Goutham Vasireddi helped make it faster and easier for developers to write add-on modules for OpenMRS by creating a “wizard” for Maven.
  • Jelena Skorucak reworked the attributes a person has within OpenMRS, giving clinics the flexibility to record more information about the persons.
  • João Portela made significant improvements to our HTML Form Entry editor, allowing non-programmers to create more detailed, useful data collection forms for health care.
  • Piotr Bryk enhanced our Metadata Sharing module to make it easier to manage the export and import of OpenMRS system configurations.
  • Rahul Akula’s work helped make it possible for OpenMRS to interoperate with external laboratory information systems.
  • Sai Manohar Nethi worked to create a framework for a comprehensive Human Resource add-on module for OpenMRS, allowing the system to help manage clinic personnel.
  • Sreya Janaswamy created a way for OpenMRS users to translate phrases used by the application into other languages, inside the application itself.
  • Sriskandarajah Suhothayan created a way for the OpenMRS Notifiable Condition Detector module to watch for certain large-scale patterns and send notifications to clinicians via SMS or e-mail.
  • Suranga Kasthurirathne created a new way for OpenMRS to store clinical observations that reference other people or locations.
  • Taras Chorny built a system to allow OpenMRS to be installed and upgraded using a variety of languages.
  • Victor Chircu built an “Atlas” add-on module that allows OpenMRS users to opt-in to report their location, type of clinic, and number of patients on a shared map to represent the active OpenMRS community.
Since we started participating in Google Summer of Code, we’re very proud that so many of our students have stayed active in the OpenMRS community and continued to contribute their talents after the program ended. In fact, three of our students have gone on to become full-time OpenMRS developers paid by various organizations involved in our community.
We continue to be more and more impressed with the students who are interested in our work, and are proud to welcome them into the OpenMRS family! In fact, this year, 2011 Google Summer of Code student Suranga Kasthurirathne was able to join us in October for our annual OpenMRS implementers meeting in Kigali, Rwanda. Suranga provided some excellent feedback about his involvement in Google Summer of Code this year, and about his experience meeting the OpenMRS community face to face. Read his blog post for more of his thoughts.
Once again, this year we were blown away by our amazing students during Google Summer of Code.