Best Practices: Element Identification with ID and AutomationID

Tuesday, March 01, 2011 by Daniel Levy | Comments 1

As a QA professional, it’s important to get involved with the development team early on in the process. This article will discuss just one of the many benefits in doing so – coding standards and the use of ID’s for enhanced team productivity. Require this up front and you can significantly cut back test case maintenance.

No matter what software you use for your test automation, the method in which elements are identified plays a critical role. Small changes to your application can often break the test’s ‘find logic’ causing your test runs to fail. Let’s say a couple elements are moved to another location on the page - if ID’s are not present, then alternative find logic is used to locate the element. Such find logic includes identification techniques such as Tag Indexes, NodeIndexPath, XPath and HTMLPath.

I’ll use Tag Indexes as my example – if my find logic says locate the tenth <DIV> tag (DIV:9), and the application changes making the target element now the ninth <DIV> tag, your script has just been broken – time to drop into maintenance mode.

Stop the madness.

Ask your development team to implement ID’s for your dynamic HTML applications or Automation ID’s for your Silverlight applications. As long as the ID’s are unique, your element repository will not require maintenance when changes are made to your application.

Our Automated Testing Tools do an amazing job at automatically identifying elements for you – this saves countless hours and allows you to continue the expansion of your regression suite while keeping your project on schedule. Why not take this to the next level by implementing ID’s as a coding standard and substantially reducing your test case maintenance time.

Silverlight Users – read more on the AutomationProperties.AutomationID Attached Property

Dynamic HTML Testers – read more on the Element ID Attribute

1  comments

  • Craig 21 Mar 2011

    We are currently ramping up our Automated UI testing effort using Telerik WebUI Studio.  As Dan said, naming all of your elements, no matter how tricky, is the key to making your tests virtually maintanance free.  I spent about 3-4 days getting most of our controls uniquely named, and so far it has paid off.



    I noticed the find logic could have around 50 elements to search through before finding the correct element.  Sometimes the test would succeed, sometimes it would fail.  Here is an example of the search logic it had to find a simple "button".



    /window[2]/grid[name=Root]/grid[1]/grid[name=ContentGrid]/border[2]/contentpresenter[name=Content]/genericlistdetails[0]/border[0]/grid[0]/contentpresenter[0]/grid[0]/grid[name=xgdSectionsLayoutPanel]/frozensectionscontainer[0]/grid[name=pgdLayoutRoot]/sectionslayout[automationid=pctrlFrozenSectionsLayout]/grid[name=Root]/border[name=Border]/scrollviewer[0]/border[0]/grid[0]/scrollcontentpresenter[name=ScrollContentPresenter]/itemspresenter[0]/stackpanel[0]/sectionslayoutitem[automationid=sec0]/grid[0]/border[name=Background]/grid[0]/grid[0]/contentcontrol[name=ExpandSite]/contentpresenter[0]/scrollviewer[0]/border[0]/grid[0]/scrollcontentpresenter[name=ScrollContentPresenter]/grid[name=pgdContentLayout]/contentpresenter[0]/grid[0]/usitextbox[automationid=17745_0]/grid[name=RootElement]/border[name=Border]/grid[0]/border[name=MouseOverBorder]/scrollviewer[automationid=ContentElement]/border[0]/grid[0]/scrollcontentpresenter[name=ScrollContentPresenter]/textboxview[0]


    Now, since we have named all of our elements uniquely, all of this search logic is no longer needed and the element is found 100% of the time, and thus our tests pass, and only fail due to real errors in our code.



Add comment

  1. Formatting options
       
      
     
     
       
  2. (optional, emails won't be shown on public pages)
  3. (optional)