Run Selenium web-driver test in remote machine

This is the step by step tutorial for automating web application using selenium web-driver (aka Selenium 2.0) in remote machine. Hope you are familiar with Ruby language and web-driver commands. Also make sure you have Java, Ruby web-driver and Firefox installed.

For better understanding let’s say there are two machines “hub” (IP: 192.168.10.10) and “remote” (IP: 192.168.10.11). This example is for default settings. You can also s run the stand alone server in different ports

Download selenium stand alone server from here http://code.google.com/p/selenium/downloads/detail?name=selenium-server-standalone-2.37.0.jar&can=2&q

For starting Hub:

Open command prompt in “hub” (IP: 192.168.10.10) machine and run selenium stand alone server by following command:

java –jar selenium-stadalone-server.jar –role hub

For starting node:

Open command prompt in “remote” (IP: 192.168.10.11) machine and run selenium stand alone server by following command:

java –jar selenium-stadalone-server.jar –role node –hub http://192.168.10.10:4444/grid/register

Launch test in hub machine:

Watch your remote machine; firefox browser will open, will browse google.com and will search for “Test”. Finally you will see a screenshot in your hub machine.

 

Automate Applet window by Selenium 2 and Sikuli

Handling Web Applet is a big headache while creating automation script with Selenium. Other windows can be handled by their Instance or Class but Applet window does not show any different Instance or Class for its content. Suppose, if we want to click a upload button in an Applet window, we won't get any separate Instance or Class for this Upload button. If we try any window information tool (e.g. AutoIt window info) and point to the Upload button, it will show the Instance/Class of the whole Applet window not the information of the button. So far, I have found solutions by pointing the position of the button in the script. But it will be a huge problem if the resolution of the window changes. Moreover, position based clicking sometime shows strange result.

To solve this problem, I have combined 2 widely used library - Selenium 2 and Sikuli, where the Sikuli library will handle the Applet window. Hope you already have a little idea on Eclips, Selenium 2 and Sikuli. This script is written in Java. Before you start, make sure you have Java installed.

1. At first Create a new project in Eclips. Name of my project is "testApplet"



2. Download Selenium 2, Download and install Sikuli

3. Right click on project name in "Package Explorer" , hover on New and then add a new folder. Name the folder "lib" (You can use any name for the folder, this folder will contain the jar files of Selenium 2 and Sikuli). Now go to the workspace of Eclips and search for the directory with project name (e.g. testApplet), open this directory. Search for the "lib" directory, copy "selenium-server-standalone-2.x.jar" and "sikuli-script.jar" to this directory. You will find "sikuli-script.jar" in this location - "C:\Program Files\Sikuli X". Now Right click on Project name, Build Path>Configure Build Path>Add External JARs and select the "jar" files in the "lib" directory.Library adding process can be simply done by Adding External Jars in projects Build Path without copying the library to workspace directory, but I always prefer above process to make the project independent.



4. Now Refresh the Project Explorer, you will see two jar files will be added into the "lib" folder, and there will be 2 "Referenced Libraries"

5. Add a new java file. Right click on source, New>File, Name the file "Main.java" or anything you want.

6. Add another folder in Project Explorer named "img". Go to http://www.java.com/en/download/testjava.jsp and capture the screenshot of the link "Sun Microsystems.Inc". Save the image on "img" directory of the workspace. Refresh the Explorer window and you will get a view like this:




7. Now we will try to click on "Sun Microsystems.Inc" link in the Applet window. Paste the following code on "Main.java" -

import org.openqa.selenium.firefox.*;
import org.openqa.selenium.WebDriver;
import org.sikuli.script.Screen;

public class Main
{
  public static void main(String[] args)
  {
    String sUrl = "http://www.java.com/en/download/testjava.jsp";

    // Instantiate the Internet Explorer browser.
    WebDriver mydriver = new FirefoxDriver();
          
    // Open the main webpage.
    mydriver.get(sUrl);
    Screen s = new Screen();
    //Click on the content of Applet;
    try{s.click("img/appWindow.png",0);
    }
    catch(Exception e){
        e.printStackTrace();
    }   
  }
}
8. Run the Project. Check the mouse movement over "Sun Microsystems.Inc" and the magic click will navigate you to the http://java.com/en/ web site. If you having problem with getting the Applet window in http://www.java.com/en/download/testjava.jsp, you need to update your Java or need to click on "test the currently installed version of Java" link by Selenium command (hope it is the most easy job for you :)).

9. That's it, you have clicked a link in the Applet window. Now you can automate anything inside the Applet window. Enjoy automated testing!

Classic Principles for Test Design

A good test case should have an expected output or result. Otherwise, testing becomes what Beizer calls “kiddy pool,” where whatever pocket the ball happens to end up in is declared the intended pocket.

Your tests should cover both valid, expected conditions and invalid, unexpected conditions. This principle perhaps seems almost too obvious for words, but it’s amazing how often people don’t adequately cover the error conditions. There are many reasons, including the fact that for many systems there are considerably more error conditions than non-error conditions.

You are most likely to find bugs when testing in those areas where you’ve already found the most bugs. This may surprise you, but this rule is borne out again and again. Bugs cluster due to the complexity of certain regions in the system, communication problems between programmers, programmer ability problems, and the gradual accumulation of too many hasty patches on a buggy area.

You should consider a test case good when it is likely to detect a bug you haven’t seen yet, and you should consider a test case successful when it does so. In other words, try to create tests that are likely to find a wide variety of bugs, and be happy when your tests do find bugs. I would generalize these statements to say that you should design test cases so that you can learn something you didn’t already know from each test case, and you should be happy when you do learn something from your tests. Furthermore, you should ideally learn the scariest, most dangerous facts first whenever possible. These outlooks help shape your work designing and creating tests.

Myers wrote that the test set should be the subset of all possible test cases with the highest probability of detecting errors. Of course, the set of all possible tests is infinite for any real-world system. Thus, there are infinite possible subsets too. Myers says that we should pick subsets based on the likelihood of bugs.