Wednesday, October 8, 2014

Mobile Emulation in ChromeDriver 2.11

ChromeDriver 2.11 release has the mobile emulation support using Chrome Dev Tools. I have been waiting for this feature since long.

This is how we can emulate different devices using the Java code.



import java.util.HashMap;
import java.util.Map;

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.chrome.ChromeOptions;
import org.openqa.selenium.remote.DesiredCapabilities;


public class MobileEmulation {
 static DesiredCapabilities  capabilities;
 static String DeviceName;
 public static void main(String[] args) {
  //some Sample Devices. Complete list can be found here: https://code.google.com/p/chromium/codesearch#chromium/src/chrome/test/chromedriver/chrome/mobile_device_list.cc
  //pick any of the device
  
//  DeviceName = "Google Nexus 5";
//  DeviceName = "Samsung Galaxy S4";
//  DeviceName = "Samsung Galaxy Note 3";
//  DeviceName = "Samsung Galaxy Note II";
//  DeviceName = "Apple iPhone 4";
  DeviceName = "Apple iPhone 5";
//  DeviceName = "Apple iPad 3 / 4";

  String ChromeDriverPath = System.getProperty("user.dir") + "/lib/chromedriver.exe";
  System.setProperty("webdriver.chrome.driver", ChromeDriverPath);
  
  Map<String, String> mobileEmulation = new HashMap<String, String>();
  mobileEmulation.put("deviceName", DeviceName);
  
  Map<String, Object> chromeOptions = new HashMap<String, Object>();
  chromeOptions.put("mobileEmulation", mobileEmulation);

  capabilities = DesiredCapabilities.chrome();
  capabilities.setCapability(ChromeOptions.CAPABILITY, chromeOptions);
  WebDriver driver = new ChromeDriver(capabilities);
  
  driver.manage().window().maximize();
  driver.navigate().to("http://www.google.com");

 }

}

Tuesday, October 7, 2014

Quick Tips on ChromeDriver - Part 1

To Change the default download directory in chrome using WebDriver Java Bindings and ChromeDriver.

1
2
3
4
5
6
7
8
9
ChromeOptions options=new ChromeOptions();
DesiredCapabilities  capabilities = DesiredCapabilities.chrome();
Map<String, Object> prefs = new HashMap<String, Object>();
prefs.put("profile.default_content_settings.popups", 0);
prefs.put("download.default_directory", "D:\\downloads");
prefs.put("savefile.default_directory", "D:\\downloads");
options.setExperimentalOption("prefs", prefs);
capabilities.setCapability(ChromeOptions.CAPABILITY, options);
WebDriver driver = new ChromeDriver(capabilities);


To Use a custom profile in ChromeDriver which can be utilized for many use cases:

1
2
3
4
5
      ChromeOptions options=new ChromeOptions();
      DesiredCapabilities  capabilities = DesiredCapabilities.chrome();
      chromeoptions.addArguments("user-data-dir="+chromeprofilepath);
      capabilities.setCapability(ChromeOptions.CAPABILITY, options);
      WebDriver driver = new ChromeDriver(capabilities);



Capturing Network Traffic Generated by Eclipse IDE

To Capture the network traffic generated by Eclipse IDE, you just need to place the following code where we are passing the proxy host and port on which your proxy tool is running.

We can use any of the proxy tool like Charlesproxy or Fiddler to do this.


System.setProperty("http.proxyHost", "IP or Hostname");
System.setProperty("http.proxyPort", "8888");
System.setProperty("https.proxyHost", "IP or Hostname");
System.setProperty("https.proxyPort", "8888");

Sunday, October 5, 2014

MY UNFORGETTABLE JOURNEY TO SELENIUM CONFERENCE 2014



It is with sheer delight that I am writing this blog to narrate my experiences of attending the SeConf 2014 in Bangalore, India. I am extremely passionate about Functional Automation and have spent more than 9 years of my career in this field. In these initial years I used to enjoy working on a tool called QTP developed by a company called Mercury.
I can still remember when I heard the word ‘Selenium’ for the first time from one of my colleagues while working at Oracle. My instant reaction was that it was some chemical and after some Googling, I realized I was right. It was only after a couple of days that I came to know from the same colleague that what he meant from the word “Selenium” was not a chemical but the open-source functional automation tool.
After further doing some research I found out that the gentleman who created Selenium thinks that it is better than Mercury QTP tool and that’s the reason he named it Selenium (which poisons mercury). I was taken aback when I first heard this but later decided to learn and master this tool, a step which if I had not taken would have ruined my chances to progress in the existing job. It was this decision that my journey to learning Selenium got started.
SeConf 2014
Amit Rawat (far right) on stage taking questions from the audience at the SeConf 2014. 
After working for five years on this tool, one day I came to know that the 4th Selenium Conference would be held for the first time in India and I had the opportunity to represent my company at this conference. It was certainly a dream come true for someone who is an avid learner of Selenium. I thought I would make the most out of this opportunity by sharing my knowledge, which I gathered over the years on this tool. I proposed a session to speak at the conference on testing responsive web applications using Appium and the WebDriver API. Even though my proposal wasn’t selected, I was happy with the fact that I managed to get 27 likes on the idea.
After much anticipation, it was finally D-Day for the conference, which started with long queues at the registration desk. There must have been around 400 other attendees representing more than 100 different companies in this event. Keynote SeConf2014
Day 1 started with the keynote presented by the “man himself” Simon Stewart, who created Selenium WebDriver. It was an amazing experience to see him in-person and to hear him discuss the future roadmap of Selenium. A few important announcements made in the keynote were:
  • Selenium RC would not be part of the upcoming release of Selenium 3.0. So this was a final call and warning to all the people to upgrade from RC to WebDriver.
  • Selenium 3.0 will standardize the API by coming up with a well-defined W3 Spec after which all browsers implementation will follow. So it would definitely make developers’ lives easier by using the same approach across all browsers.
  • Selenium 3.0 will have no support for mobile browsers and the alternative solutions like Appium, iOSDriver, and Selendroid can be used for Mobile automation.
Apart from the keynote, I got a chance to attend some really good sessions. I especially liked the session presented by Jim Evans, where he showed how a company like Microsoft, whose executives used to compare open-source software to a virus, has changed its mindset in no time. Now the same company has started contributing to open-source projects like Selenium by providing their own WebDriver implementationfor Internet Explorer. This change of stance clearly shows the power of the open-source movement.
Another interesting session which I personally liked was “Scaling and Managing Selenium Grid” by Dima Kovalenko, who is also one of the Selenium committers. In this session he shared minute details about Selenium Grid configurations and some best practices, like always running a single grid node on a machine. So it is always recommended to have a dedicated VM for a single browser node rather than having multiple nodes running on a powerful machine. He also shared a very useful toolcreated by him to manage Selenium Grid configurations.
During the session breaks I interacted with many other attendees including the Selenium core committee members and tried to understand how they are utilizing this wonderful tool and what improvements they want to see in this tool. I got some amazing ideas during those interactions and I would surely like to try them in due course.
The biggest moment of the conference for me came when the Fish Bowl session started and I got the privilege to share the dais with the Selenium core committee including Simon, its founder. It was such a privilege to answer audience queries, one of which was a question related to mobile browser emulation using ChromeDriver.
Overall, it was an enriching experience for me to attend this conference, where I learnt so many new things and networked with the Selenium community.

Thursday, October 17, 2013

Appium: A Cross-Platform Mobile Automation Tool

Appium is an open source test automation tool developed and supported by Sauce Labs to automate native and hybrid mobile apps. It uses JSON wire protocol internally to interact with iOS and Android native apps using the Selenium WebDriver.  
There are many other automation tools available in market to automate mobile native apps like MonkeyTalk, KIF, Calabash and Frank but most of those tools require an extra agent needs to be compiled with your application code so that the tool can interact with the mobile app. So here the problem is the app which you will be testing is not the same app which you will be submitting in the App Store as you would need to remove those automation agent libraries before submitting the app. 
Automating hybrid and native mobile applications for Android and iOS is a key function handled by Appium, a node.js server. One of the core tenets of Appium is that test codes can be written in any framework or language like Ruby on Rails, C# and Java without having to modify the apps for automation purposes. The interaction between node.js server and Selenium client libraries is what ultimately works together with the mobile application. Appium is open source and can seamlessly run on a variety of devices and emulators making it an apt choice for mobile test automation.
At present Appium only supports Android and iOS based apps but support for Firefox mobile OS is in pipeline.
Appium’s Architecture
Appium is an HTTP server written in node.js which creates and handles multiple WebDriver sessions for different platforms like iOS and Android. 
Appium starts a "test case" on the device that spawns a server and listens for proxied commands from the main Appium server. It is almost same as Selenium server which perceives http requests from selenium client libraries and it handles those requests in different ways depending upon the platforms. Each vendor like iOS and Android have a different way and mechanism to run a test case on the device so Appium kind of hacks in to it and run this testcase after listening commands from appium server.
How Appium works in iOS:
On iOS, Appium proxies command to a UIAutomation script running in Mac Instruments environment. Apple provides this application called ‘instruments’ which is used to do lot activities like profiling, controlling and building iOS apps but it also has an automation component where we can write some commands in javascript which uses UIAutomation APIs to interact with the App UI. Appium utilizes these same libraries to automate iOS Apps.

Appium

In the above figure, we can see the architecture of the Appium in context to the iOS automation. If we talk about a command life-cycle, it goes like, Selenium webdriver picks a command form the code like (Element.click) and sends it in form of JSon via http request to the Appium server.  Appium server knows the automation context like the iOS and Android and sends this command to the Instruments command server which will wait for the Instruments command client (written in node.js) to pick it up and execute it in bootstrap.js with in the iOS instruments environment. Once the command is executed the command client sends back the message to the Appium server which logs everything related to the command in its console. This cycle keeps going till the time all the commands gets executed.
How Appium works in Android:
The situation is almost similar in case of Android where Appium proxies commands to a UIAutomator test case running on the device. UIAutomator is Android's native UI automation framework which supports running junit test cases directly in to the device from the command line.It uses java as a programming language but Appium will make it run from any of the WebDriver supported languages.
Appium

In the above diagram we can see, here we have Bootstrap.jar in place of bootstrap.js which represents out test case when compiled in java. As soon as it gets launched it spawns a TCP server. Here the TCP server resides inside the device and client is in the Appium process which is just opposite to the way it is in iOS.
Appium’s Pros and Cons:
Pros:
  • The beauty of Appium is that, all the complexities are under the hood of Appium server and for an automation developer the programming language and the whole experience would remain same irrespective of the platform he is automating (iOS or Android).
  • The other benefits of Appium is that it opens the door to cross-platform mobile testing which means the same test would work on multiple platforms.
  • Unlike other tools Appium doesn't require you to include some extra agents in your app to make it automation friendly. It believes in the philosophy of testing the same app which we are going to submit in the app store.
  • It is developed and supported by Sauce Labs and it is getting picked really fast with in the WebDriver community for mobile automation.
  • It can automate Web, Hybrid and Native mobile applications.
     
Cons:
  • Scaling up is an important consideration with Continuous Integration and Appium comes across as a great tool to fulfill this expectation. The reason for this is a technical limitation, in iOS we can only run one instance on Instruments per Mac OS so we can only run our iOS scripts on one device per mac machine. So if we want to run our tests on multiple iOS devices at the same time then we would need to arrange the same number of Mac machines, which would be costly affair. But this limitation can be resolved if we execute our scripts in Sauce Lab's mobile cloud which at present supports running scripts on multiple iOS simulators at the same time.
  • Appium uses UIAutomator for Android automation which only supports Android SDK Platform, API 16 or higher so to support the older APIs they have used another open source library called Selendroid. So I would not say it as a limitation but it is definitely an overhead on the configuration side.
     
To Configure Appium on Mac
Following configurations are required to run Appium on Mac:
  • First we need to download the Appium app for Mac from this link. Once downloaded you need to move this app in to your applications folder and then you can launch it from your Mac Launchpad.
  • As Appium uses node.js internally so we would also need to install node on the mac machine, which can be downloaded from http://nodejs.org/ , it will download a node-v0.10.xx.pkg file which you need to install.
  • We also need to make sure we are using Mac OSX 10.7+
  • XCode 4.5 or higher version along with iPhone simulator SDK and Command Line Tools should be installed on the mac machine.