Alexander (Sasha) Sirotkin works on the LTE (Long Term Evolution) Project at Comsys Mobile. Alexander can be reached via e-mail at [email protected]
A Web developer's life has never been easy. Browser market fragmentation, poor standards compliance, and the sheer number of web programming languages and tools all add up to challenges when trying to satisfy user demands and keeping up with ever changing web technologies and trends. And with what appears to be a second browser war underway, the situation is probably not going to get better any time soon. As if this isn't, the advent of cellular broadband access brought to the collection of browsers that you have to test against a handful of new ones, sometimes with limited functionality and non-standard screen resolution. In short, these days you can no longer afford to test your site with just your favorite browser.
Figure 1 shows a typical Selenium test system in which the Selenium client library communicates with the Selenium server via TCP/IP.
Now that you have some understanding of what Selenium is and how it works, it is time to write some code. The following Selenium RC example makes a simple Internet search with Google. It is implemented in Java (as all the rest of the examples in this article):
Selenium selenium = new DefaultSelenium("localhost", 4444, "*iexplore", "http://www.google.com"); selenium.start(); selenium.open("/"); selenium.type("q", "42"); selenium.click("btnG"); // Do some stuff selenium.stop();
The code is rather self-explanatory, so I will only describe the important arguments of each command. This example assumes that both the client and the server (Selenium server, not the web server) run on the same machine, i.e. localhost and the server is configured to listen on the port number 4444. The *iexplore parameter tells Selenium to use a certain Internet Explorer profile (more on this later). Commands type and click accept HTML element name or id as their first argument, which you, as a web site developer of your own site under test, should know.
The "BrowserString" parameter (*iexplore) is very important and unfortunately poorly documented. If you only have to test with Firefox and Internet Explorer you can simply use *firefox and *iexplore respectively and forget about this. However, if you need to test with additional browsers, read on.
Same Origin Policy
At this point you may think that this the mode you should use for you tests, but unfortunately during the Selenium development people discovered that some important functionality is very hard to implement in this mode and gradually most developers switch to the so called "native" mode, even though it requires a separate implementation for every browser. As a result, the PI mode is poorly maintained and quite buggy. For instance, during my experiments I was surprised to discover that the PI mode does not handles correctly encoding other than Unicode!
If you decide to try the PI mode anyway you may think that the way to enable it would be to use the Proxy Injection mode profiles *pifirefox and To summarize: As a rule of thumb remember that you should try to avoid using the Proxy Injection mode and use *firefox and *iexplore modes instead. However, if you have to test with less popular browser for which there is no good native mode implementation and the same origin policy is an issue. Be prepared that some of Selenium functions will simply not work.
To summarize: As a rule of thumb remember that you should try to avoid using the Proxy Injection mode and use *firefox and *iexplore modes instead. However, if you have to test with less popular browser for which there is no good native mode implementation and the same origin policy is an issue. Be prepared that some of Selenium functions will simply not work.