Test, UI Code Convention for Web Applications

Conventions for Web Applications

The conventions below is to support the test team in adding unique IDs of some kind to page element for automated testing. The following elements have been deemed as a minimum for having these IDs.

• <a>
• <button>
• <form>
• <input>
• <object>
• <option>
• <select>
• <textarea>

The following list of items also require IDs if used.

• onkeydown
• onkeypress
• onkeyup
• onclick
• ondblclick
• onmousedown
• onmousemove
• onmouseover
• onmouseout
• onmouseup

Anything else that may require a unique ID should be requested by the test team on a case by case basis.

The breakage of the conventions above may cause problems during Test Case implementation (including the possibility that a Test Case implementation become not possible/reliable).

Test Automation may require to add id attribute to an element type, which is not listed above. Be prepared for this, and help test automation by adding the id upon request.

And the most critical:

When a change is about UI change, or a change influences the UI, the change might break the automated test scripts. The maintenance time of the test scripts should be considered and estimated during the triage + after the UI change the related tests shall be executed and corrected, if it is necessary...

Case studies on problematic webpage content

Example 1:

On a page, it's pretty hard to parse a price data, since there is no identifier for the columns. It would be nice to have identifiers, like 'Mon', 'Tue', 'Wed', 'Thu', ...

Current setup

<table>
  <tr>
    <td>
      <strike>$365</strike>
      <span>**$292**</span>
    </td>
    <td>
      <strike>$365</strike>
      <span>**$292**</span>
    </td>
  </tr>
</table>

Suggested

<table>
  <tr>
    <td class="T_mon_0">
      <strike>$365</strike>
      <span>**$292**</span>
    </td>
    <td class="T_tue_0">
      <strike>$365</strike>
      <span>**$292**</span>
    </td>
  </tr>
</table>

Don't use duplicated IDs

As we don't have a full proof method of preventing duplicate IDs from being used we need to use class names instead of IDs as precautionary measure. The class names that are used only for test reasons should be pre-pended with T_. However if an id is already available there is no need to add one simply for test.

We also need to make sure the names are sufficiently obscure to avoid duplication. However we also need to keep the length down to minimize bloat. One method that will help is to use part of the unique css namespace for each module as part of the test hook.

Please note that HTML page size is increasing when we start using classes/ids.

Responsibilities

The responsibilities for implementing these ids lay on both the UI and Dev teams. As most of the elements that need to be tagged are form elements, these will usually be done by the dev team, but with some exceptions.

One exception is that the UI team will still be implementing IDs on input fields as these need to be related to the label for attribute.

<label for="first_name">First name</label>
<input type="text" id="first_name" />

The UI team will also deal with static links while the dev team should add the ids to any generated / looped HTML and form elements.

Any ids necessary on elements not described in the list above should be requested by the test team.

Risks

Using classes instead of IDs in most cases will eliminate issues with duplicate IDs breaking JavaScript functionality. There is still a risk of duplicate class names preventing a test from running but this is less of an issue than the page breaking. If the rules above a followed this risk should be minimal.

The other risk/annoyance is that we are adding extra bloat to the markup. We should refrain from adding ids to every element and only do so where necessary. For example, there is no point in adding an id to every anchor in a list of 100 generated anchors.