Many are familiar with using WebDriver for automated web application testing. Using Geb takes that to the next level, by combining the power of WebDriver with the power of JQuery and Groovy. For mobile web applications, we can use all this and not simply automate testing in Firefox, or in Firefox with a mobile user agent, but on the devices themselves! Currently, Android and iOS devices are supported – this post takes a look at setting up testing on an iPhone or iPad device. As mobile applications leverage more and more features from HTML5, CSS3, and other similar technologies, it becomes more and more evident that emulators and browser user-agents can only go so far in showing how your applications truly work on a device. In short, you’ll find that they (and I’m letting you in on a secret here) – lie to you! In addition, one wouldn’t consider their mobile web application QA tested if it ran in a browser and an emulator only – so why would (or better said, should) that be satisfactory for automated testing?

Selenium’s iPhoneDriver documentation provides details on setting up XCode and your device for running RemoteWebDriver (iWebDriver in this case). Be sure that you have a developer license and a provisioning profile so that you can run the iWebDriver application on your iOS device. Also, be sure that the device you are running your Geb tests on and your iOS device can see each other on the same network.

Testing with XCode 4.3 and iOS 5.1, the instructions worked nearly flawlessly, with the longest delay being simply the downloading of all of the Selenium source code. Hang-ups you might run into would be in your XCode build settings, so be sure you have properly code signed the project/target and setup a valid architecture. Issues in this area trip up iOS newbies and non-newbies alike, enough so that if you run into something searching for the solution will quickly turn up the steps you need to take.

The RemoteWebDriver should now be running on your iOS device and look similar to:

The (full) url provided at the bottom of the screen will be the one configured with the ‘localiphoneip’ config value we’ll demo in our sample test later.

Speaking of – so how to run these tests on the device once things are “setup”? The syntax referenced on the Geb website for RemoteWebDriver is definitely nice for making sure your code knows where the RemoteWebDriver resides (ignoring the choice of IE portion of the example, if not the win portion also…), in that you can set up an environment based system property that defines where the RemoteWebDriver is running:

One could see not only doing this depending on which environment the tests were running in, but also incorporating the ability for developers to override this url in their own Config.groovy file (which I recommend) and accessing the config value during test setup. Using an environment configuration approach also works well for running your same test suite on different devices. You may want to, for example, run your tests once with a geb.env for an iOS device, and then again for a Android device. An environmental configuration for this type of scenario works better than a base class approach, which does work well in a single device testing scenario, and is described by Tomas Lin in this blog post.

So what might a test look like?

Future steps

From testing on other devices, to capturing images/video of test executions (GebReportingSpec?), to leveraging Selenium Grid 2, to running tests in the cloud against actual devices (via DeviceAnywhere or someday Sauce Labs), the future of mobile automated testing holds many possibilities. Join in the discussion by trying to create some automated web tests on actual devices using Geb and Spock, and together let’s create the automated mobile webapp testing solutions of the future!