Verifying UI elements on a web page is probably the
most common feature of your automated tests. Selenese allows multiple ways of
checking for UI elements. It is important that you understand these different
methods because these methods define what you are actually testing.
For example, if you are testing a text heading, the
text and its position at the top of the page are probably relevant for your
test. If, however, you are testing for the existence of an image on the home
page, and the web designers frequently change the specific image file along
with its position on the page, then you only want to test that an image (as
opposed to the specific image file) exists somewhere on the page.
Assertions are statements of the code that check whether
the pages loading are as per the requirements. A failed assertion will lead to
a failed script. testNG provides quite a many assertion methods of which we
will use a few.
Verification are statements of the code that do the exact
same things that assertions do, however a failed verification won’t lead to a
failed script. testNG does not provide verification methods as such but we can
design our own verify methods and add them to our reusable code.
Choosing between “assert” and “verify” comes down to
convenience and management of failures. There’s very little point checking that
the first paragraph on the page is the correct one if your test has already
failed when checking that the browser is displaying the expected page. If
you’re not on the correct page, you’ll probably want to abort your test case so
that you can investigate the cause and fix the issue(s) promptly. On the other
hand, you may want to check many attributes of a page without aborting the test
case on the first failure as this will allow you to review all failures on the
page and take the appropriate action. Effectively an “assert” will fail the
test and abort the current test case, whereas a “verify” will fail the test and
continue to run the test case.
The best use of this feature is to logically group
your test commands, and start each group with an “assert” followed by one or
more “verify” test commands. An example follows:
Command Target Value
open /download/
assertTitle Downloads
verifyText //h2 Downloads
assertTable 1.2.1 Selenium IDE
verifyTable 1.2.3 1.0 beta 2
The above example first opens a page and then
“asserts” that the correct page is loaded by comparing the title with the
expected value. Only if this passes will the following command run and “verify”
that the text is present in the expected location. The test case then “asserts”
the first column in the second row of the first table contains the expected
value, and only if this passed will the remaining cells in that row be
“verified”.
The command verifyTextPresent is used to verify
specific text exists somewhere on the page. It takes a single argument–the text
pattern to be verified. For example:
Command Target Value
verifyTextPresent Marketing Analysis
This would cause Selenium to search for, and verify,
that the text string “Marketing Analysis” appears somewhere on the page
currently being tested. Use verifyTextPresent when you are interested in only
the text itself being present on the page. Do not use this when you also need
to test where the text occurs on the page.
Use this command when you must test for the presence
of a specific UI element, rather than its content. This verification does not
check the text, only the HTML tag. One common use is to check for the presence
of an image.
Command Target Value
verifyElementPresent //div/p/img
This command verifies that an image, specified by
the existence of an <img> HTML tag, is present on the page, and that it
follows a <div> tag and a <p> tag. The first (and only) parameter
is a locator for telling the Selenese command how to find the element. Locators
are explained in the next section.
verifyElementPresent can be used to check the
existence of any HTML tag within the page. You can check the existence of
links, paragraphs, divisions <div>, etc. Here are a few more examples.
Command Target Value
verifyElementPresent //div/p
verifyElementPresent //div/a
verifyElementPresent id=Login
verifyElementPresent link=Go
to Marketing Research
verifyElementPresent //a[2]
verifyElementPresent //head/title
These examples illustrate the variety of ways a UI
element may be tested. Again, locators are explained in the next section.
verifyText
Use verifyText when both the text and its UI element
must be tested. verifyText must use a locator. If you choose an XPath or DOM
locator, you can verify that specific text appears at a specific location on
the page relative to other UI components on the page.
Command Target Value
verifyText //table/tr/td/div/p This is my text and it occurs right
after the div inside the table.
Locating
Elements
For many Selenium commands, a target is required.
This target identifies an element in the content of the web application, and
consists of the location strategy followed by the location in the format
locatorType=location. The locator type can be omitted in many cases. The
various locator types are explained below with examples for each.
This is probably the most common method of locating
elements and is the catch-all default when no recognized locator type is used.
With this strategy, the first element with the id attribute value matching the
location will be used. If no element has a matching id attribute, then the
first element with a name attribute matching the location will be used.
For instance, your page source could have id and
name attributes as follows:
<html>
<body>
<form
id="loginForm">
<input
name="username" type="text" />
<input
name="password" type="password" />
<input
name="continue" type="submit" value="Login" />
</form>
</body>
<html>
The following locator strategies would return the
elements from the HTML snippet above indicated by line number:
identifier=loginForm (3)
identifier=password (5)
identifier=continue (6)
continue (6)
Since the identifier type of locator is the default,
the identifier= in the first three examples above is not necessary.
This type of locator is more limited than the
identifier locator type, but also more explicit. Use this when you know an
element’s id attribute.
<html>
<body>
<form
id="loginForm">
<input
name="username" type="text" />
<input
name="password" type="password" />
<input
name="continue" type="submit" value="Login" />
<input
name="continue" type="button" value="Clear" />
</form>
</body>
<html>
id=loginForm (3)
The name locator type will locate the first element
with a matching name attribute. If multiple elements have the same value for a
name attribute, then you can use filters to further refine your location
strategy. The default filter type is value (matching the value attribute).
<html>
<body>
<form
id="loginForm">
<input
name="username" type="text" />
<input
name="password" type="password" />
<input
name="continue" type="submit" value="Login" />
<input
name="continue" type="button" value="Clear" />
</form>
</body>
<html>
name=username (4)
name=continue value=Clear (7)
name=continue Clear (7)
name=continue type=button (7)
Note
Unlike some types of XPath and DOM locators, the
three types of locators above allow Selenium to test a UI element independent
of its location on the page. So if the page structure and organization is
altered, the test will still pass. You may or may not want to also test whether
the page structure changes. In the case where web designers frequently alter
the page, but its functionality must be regression tested, testing via id and
name attributes, or really via any HTML property, becomes very important.
Locating
by XPath
XPath is the language used for locating nodes in an
XML document. As HTML can be an implementation of XML (XHTML), Selenium users
can leverage this powerful language to target elements in their web
applications. XPath extends beyond (as well as supporting) the simple methods
of locating by id or name attributes, and opens up all sorts of new
possibilities such as locating the third checkbox on the page.
One of the main reasons for using XPath is when you
don’t have a suitable id or name attribute for the element you wish to locate.
You can use XPath to either locate the element in absolute terms (not advised),
or relative to an element that does have an id or name attribute. XPath
locators can also be used to specify elements via attributes other than id and
name.
Absolute XPaths contain the location of all elements
from the root (html) and as a result are likely to fail with only the slightest
adjustment to the application. By finding a nearby element with an id or name
attribute (ideally a parent element) you can locate your target element based
on the relationship. This is much less likely to change and can make your tests
more robust.
Since only xpath locators start with “//”, it is not
necessary to include the xpath= label when specifying an XPath locator.
<html>
<body>
<form
id="loginForm">
<input
name="username" type="text" />
<input
name="password" type="password" />
<input
name="continue" type="submit" value="Login" />
<input
name="continue" type="button" value="Clear" />
</form>
</body>
<html>
There are also a couple of very useful Firefox
Add-ons that can assist in discovering the XPath of an element:
XPath Checker - suggests XPath and can be used to
test XPath results.
Firebug - XPath suggestions are just one of the many
powerful features of this very useful add-on.
Locating Hyperlinks by Link Text
This is a simple method of locating a hyperlink in
your web page by using the text of the link. If two links with the same text
are present, then the first match will be used.
<html>
<body>
<p>Are
you sure you want to do this?</p>
<a
href="continue.html">Continue</a>
<a
href="cancel.html">Cancel</a>
</body>
<html>
link=Continue (4)
link=Cancel (5)
Locating by DOM
The Document Object Model represents an HTML
document and can be accessed using JavaScript. This location strategy takes
JavaScript that evaluates to an element on the page, which can be simply the
element’s location using the hierarchical dotted notation.
Since only dom locators start with “document”, it is
not necessary to include the dom= label when specifying a DOM locator.
<html>
<body>
<form
id="loginForm">
<input
name="username" type="text" />
<input
name="password" type="password" />
<input
name="continue" type="submit" value="Login" />
<input
name="continue" type="button" value="Clear" />
</form>
</body>
<html>
Locating by CSS
CSS (Cascading Style Sheets) is a language for
describing the rendering of HTML and XML documents. CSS uses Selectors for
binding style properties to elements in the document. These Selectors can be
used by Selenium as another locating strategy.
<html>
<body>
<form
id="loginForm">
<input
class="required" name="username" type="text"
/>
<input
class="required passfield" name="password"
type="password" />
<input
name="continue" type="submit" value="Login" />
<input
name="continue" type="button" value="Clear" />
</form>
</body>
<html>
Note
Most experienced Selenium users recommend CSS as
their locating strategy of choice as it’s considerably faster than XPath and
can find the most complicated objects in an intrinsic HTML document.
No comments:
Post a Comment