November 2009
The DOM, Your Ally for
Testing Web Applications
Reap the fruit of the DOM (Document Object Model) tree,
Valery Raulet explains the relationship and interaction
of your testing tool with the GUI
S
ince the invention of
the World Wide Web
by Tim Berners-Lee in
1989, the browser has
evolved quite dramatically and it
is now capable of running Web
applications using a technology
that initially was not meant
for that purpose. The HTML1
language was created for enabling
researchers to collaborate and
share information.
Web applications have now
become so complex and are
using a mixture of HTML/XML,
JavaScript and CSS2. Web
developers need to spend a fair
amount of time learning this
technology and all the derivatives
(jQuery, Ajax, REST to name a
few) that enable them to develop
even more powerful applications.
To the automation tester, web
applications may look like a
normal application with buttons,
checkboxes, edit fields, and all
the basic GUI components.
However, if we look for a richer
interaction with the end-user,
more complex GUI components
appear such as trees, grids,
menus, windows, etc. This rich
set of features often referred as
Web 2.0 is not “standardized”
and everyone comes up with their
www.macrotesting.com
own way of implementing those
features, but still relying on the
basic building blocks that are
HTML, JavaScript and CSS.
These complex components are
usually the ones that make the
tester worry, as the automation
tool is often unable to correctly
handle them. The automated
testing tool will usually fail to
understand the essence of the
component and will instead
record low-level interactions such
as clicks here and clicks there.
Not surprisingly though, as these
components are formed using
basic building blocks. So, how do
we overcome this challenge?
Before answering this question,
let’s have a look at the
architecture of a Web browser.
Figure 1 shows the components
of a typical Browser architecture.
The elements are:
HTTP Downloader: it is in
charge of requesting the various
documents (HTML page, images,
CSS, JavaScript and any other
documents).
HTML Parser: it processes
the received HTML documents
and generates the DOM, a tree
representation of the HTML
document.
21
November 2009 Technical Corner - Document Object Model (DOM)

JavaScript interpreter: it in order to generate Firefox, Internet Explorer, Opera,

interprets the JavaScript code
either downloaded separately (.js
files) or inline (<script> tag).
DOM: a tree representation of
the displayed page.
Rendering Engine: the engine
in charge of reading the DOM
tree and generating a graphic
representation of it.
changes in the DOM
(dynamic behaviour of the
application). The changes
are reflected in the DOM
which are reflected on the
screen, and so on.
As you can see, the DOM plays
a central role in the Browser
architecture. It is actually the
cornerstone of a browser and
the differences you see between
various browsers (Chrome,
Safari, and al.) is partly due to
the way this DOM representation
is generated.
Any testing tool that seriously
supports Web applications must
have a means of accessing the
DOM giving the tester more
freedom. This functionality can
be used to:
(a) Access some DOM objects
that carry information not visible
on the screen.

A typical flow
consists of the
following steps:
1. A user types a URL which
triggers the download of a
main HTML page and all the
related resources.

2. The HTML parser processes

the HTML code and
generates the static part of
the DOM tree.

3. The downloaded JavaScript

documents and the script
enclosed in the script tag are
parsed. Their code modifies
the DOM tree.

4. The DOM represents the

Web page to be displayed
and each node is a piece of
graphical information with
its own data (type, location,
style).

5. The rendering engine

processes the DOM and
generates the graphical
representation that the user
sees in the browser.

6. The user interactions (mouse

and keyboard) generate
events that are sent to
the JavaScript interpreter

22 www.macrotesting.com
Technical Corner - Document Object Model (DOM) November 2009

(b) Allow more complex Page(“Page”).Object.all. This usually requires a strong

interactions using the structure of tags(“INPUT”)(0).outerHTML knowledge of the Web technology
the data in the DOM. (JavaScript, DOM, and HTML)
To go one step further, if your and also the language used to
(c) Interact with the DOM to
testing tool supports extensibility create these extensions.
perform actions not available to
for the Web, you can amend the
carry out with the testing tool;
behaviour of the tool in order Thanks to the DOM, you now
(d) Carry out any manipulation to automatically recognize your no longer have any limitations to
that JavaScript can do. complex GUI objects. your testing capability!
For instance, Borland SilkTest
and HP QuickTest Professional,
the two major functional testing FURTHER READING:
tools available on the market
allow this type of interaction. Internet Explorer HTML and DHTML Reference
QuickTest Professional has a http://msdn.microsoft.com/en-us/library/ms533050(VS.85).aspx
property Object that gives access
to the corresponding DOM object Mozilla Firefox Gecko DOM Reference
whereas SilkTest has a method https://developer.mozilla.org/en/Gecko_DOM_Reference
ExecMethod() that provides this
access. See both examples below:
Borland SilkTest Valery Raulet
Print(Browser.ExecMethod(“all.
Exposit Ltd
tags(“”INPUT””)(0).
outerHTML”) Director, Senior Consultant
HP QuickTest Professional www.exposit.co.uk
Print Browser(“Browser”).

www.macrotesting.com 23