Selenium Core is the heart of Selenium. It is a collection of JavaScript
functions that are used by all Selenium projects, but it is rarely used
on its own. If you take a look at the HTML source for the Web site under test
(using View→Page source in Firefox or with whichever browser you told
Selenium to execute),
you will notice some additional JavaScript code that looks
like the following:

This is actually the Selenium Core code. The way Selenium
“injects” itself into
the Web page can vary (more on this later); however, when Selenium Core is
used directly, this code has to be added to your HTML manually. Naturally,
it requires access to the Web server that's serving the page, which is not always available.
The biggest advantage of this mode is that it will work reliably
with all browsers—something that other methods of using Selenium
cannot guarantee.

Nevertheless, standalone Selenium Core is rarely used these days and may
be deprecated in the future, so for the rest of this article, I concentrate
on
Selenium RC and IDE, which are the preferred methods of using Selenium.

Selenium IDE

Contrary to Selenium RC, for which you write your test cases using
some programming language, the Selenium IDE allows you to develop your
Selenium test cases in a graphical environment by simply interacting
with the Web application under test as your users would. It probably
is the easiest way to develop test cases. Selenium IDE is implemented as
a Firefox plugin. The IDE not only records the Selenium commands that
correspond to your interactions with the browser, but it also allows you
to modify their arguments and add more commands to the recorded test
case. The plugin has a context menu that allows you to select a UI
(User Interface) element from the browser's currently displayed page and
then select a Selenium command from a drop-down list, automatically adding
relevant parameters according to the context of the selected UI element.

After installation, the IDE is accessible via Tools→Selenium IDE in the
Firefox menu. To illustrate the IDE functionality, let's re-create the
above Google search test case using the IDE. In order to do this, you
simply should run the IDE, check that the record button is on, open
the http://www.google.com page, type selenium and click Google
Search. As you type, the Selenium IDE captures what you do (Figure 3).

Figure 3. Selenium IDE Screen Capture

Selenium recorded the manually entered commands. This test
case now can be played back using the IDE, saved as HTML or exported in a
variety of formats, including ready-to-run code snippets for Selenium RC.
The exported test case looks very similar to the handwritten code above,
although in this case, I exported it in Python in
order to demonstrate some of Selenium's capabilities:

Note that in addition to using a unit-testing framework, the code above
differs from the Perl example by using the "*chrome" browser string instead
of "*firefox". This is one of the most confusing
issues with Selenium,
and it deserves a section of its own here.

Browser String Parameter

Before I go into the really confusing details of this parameter, it is
important to understand that even though Selenium is not a new project,
it still is under active development, and as it sometimes happens with
open-source projects, some of the development effort that went into introducing
new features might have been better spent debugging old ones and making it more
stable. As a result, in certain configurations, some Selenium features
might not work as expected, and others may not work at all.

The browser string parameter not only specifies the browser Selenium will
work with, but also the method Selenium uses to control the browser and
the mode of communication between the Selenium server and the Selenium
Core running inside the browser. And, yes, there are multiple modes
for some browsers. Not all modes are implemented for every browser, and
some Selenium commands will not work with certain modes. To add to the
confusion, the default modes sometimes change between different Selenium
versions. In Selenium version 1.0 "*firefox" is an
alias for "*chrome"
and "*iexplore" for "*iehta".

This explains why the automatically generated
Python code produced a different value for the browser string than
was used in the manually produced Perl code, even though both tests used Firefox.
Both the "*chrome" and
"*iehta" browser profiles implement a
“native”
approach in which Selenium uses a browser-specific method to
“inject”
the Selenium Core JavaScript code and to control the browser, as opposed
to a Proxy Injection (PI) mode, which is generic and, at least in theory,
should work with all browsers.

When Proxy Injection mode is enabled, Selenium RC, which has a built-in
HTTP proxy server, configures the custom profile of the browser under
test to work with its local proxy. Every HTTP response returned by
the proxy server has had the Selenium Core JavaScript code
“injected” into
the <head> HTML element.

By design, the Proxy Injection mode works with all browsers, even
those that were not tested with Selenium, as long as the browser
supports JavaScript and an HTTP proxy. Not only that, but it also allows
circumventing the “same origin policy”—that is, it allows you to test different sites on
different domains during the same Selenium session with browsers for
which the “native” mode is not complete, for instance Opera. At this
point, you may think that this is the mode you should use for your tests,
but unfortunately, during Selenium's development the developers discovered that
some important functionality is very hard to implement in PI mode. As a
result, most developers gradually switched 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.

As you can see, even though it is often praised for its multiple browser
testing capability, in reality, browsers other than Firefox and Internet
Explorer are poorly supported. At the end of the day, if you have to
ensure that your Web site looks and works correctly under all important
browsers,
your best bet may be a browser screenshot tool, such as BrowserShots or
BrowserSeal. BrowserShots is a Web-based screenshot service supporting
a wide range of browsers that unfortunately suffers from long response
times. BrowserSeal, on the other hand, is a standalone application running
on your PC optimized for Web site screenshots. It produces screenshots
in a few seconds, compared with a few minutes for BrowserShots; however,
there is only a Windows version available at the time of this writing.

Comment viewing options

Interesting article, thanks. I've been using Selenium for functional testing, but was forced to running different browsers on different operating systems under VirtualBox for cross browser testing. BrowserSeal looks promising, will check it out.

Sponsored by:

Geek Guides

Pick up any e-commerce web or mobile app today, and you’ll be holding a mashup of interconnected applications and services from a variety of different providers. For instance, when you connect to Amazon’s e-commerce app, cookies, tags and pixels that are monitored by solutions like Exact Target, BazaarVoice, Bing, Shopzilla, Liveramp and Google Tag Manager track every action you take. You’re presented with special offers and coupons based on your viewing and buying patterns. If you find something you want for your birthday, a third party manages your wish list, which you can share through multiple social- media outlets or email to a friend. When you select something to buy, you find yourself presented with similar items as kind suggestions. And when you finally check out, you’re offered the ability to pay with promo codes, gifts cards, PayPal or a variety of credit cards.