Do not use ID to identify form level components

Form level components refer to things like buttons, text inputs, radio buttons, links, etc.

There are two reasons for not doing this:

  1. Developers should not be using IDs in the first place. ID is a global identifier within the HTML DOM, and duplicate ID values can have strange consequences . It also leads to components having long and specific names in order to somewhat guarantee their uniqueness, such as “dataEntryPanelAlphaOkButton”.
  2. In technologies like Ext JS, IDs when otherwise not manually set are auto-generated.  This means that any small change to a page, or at worse a refresh of the page, could cause the IDs to change.

 

Do not arbitrarily wait for something to happen

Due to the asynchronous nature of HTML5 technologies such as Ext JS, a lot of operations do not happen instantaneously. For this reason you have to wait for something on what are expecting to load to actually load.

The worst thing you can possibly due is pause for an arbitrary amount of time.

The reason for this is that these non-deterministic pauses in order to be remotely stable, they have to be for way too long. Even then they are still prone to not working when applied on different machines under different conditions such as load.

It is for this reason the Java API provides several wait mechanisms, as does the Gwen API. Use these mechanisms for deterministic waiting.

Don’t use human-unreadable XPath

The following XPath has a lot of problems:

/html/body/div/section/div/div[6]/div/div/div[2]/div/div/input[5]
  1. If a human being can’t understand this, they can’t maintain it
  2. A path like this is prone to failure due to a minor change in the page. For example if an additional components or div is added anywhere this XPath no longer works.

 

Use a browser that lets you inspect the rendered HTML

Knowing what is on the page is integral to be able to know how to interact with it. Chrome has the built-in ability right-click on something and select “Inspect Element”. Other browsers have similar abilities, which shows you the HTML in memory (this is different than view source as has to do with how technologies like ExtJS work).

For example consider the following page: form1.html

If you view the page source you get the following:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Form 1</title>

    <link rel="stylesheet" type="text/css" href="extjs/resources/css/ext-all.css" />

    <script type="text/javascript" src="extjs/ext-all.js"></script>

    <script type="text/javascript" src="app/form1.js"></script>

</head>
<body>

    <div id="contentDiv"></div>
</body>
</html>

However is you use the “Inspect Element” ability you see the following:

inspect_element

This is the actual HTML that you are interacting with on the page, and is what you are writing browser automation tests against.

Use a plug-in like XPather to work with XPath on a page

A plugin like XPather is important for trying out how XPath works on a site. This is especially important when dealing with a custom component that has an aspect that is not a part of any of the pre-build component helpers.

xpather