Forum Discussion

lachapan's avatar
lachapan
Occasional Contributor
7 years ago
Solved

Is there a document that provides developers with best practices for testers to ID objects using TC?

Our developers have asked us if there is a document or white paper of guidelines of things developers can do to make it easier to identify objects using TestComplete. We know the obvious one of IdStr...
  • AlexKaras's avatar
    AlexKaras
    7 years ago

    Andy,

     

    It is really good if it is possible to ask Development for the things that you need and they consider your requests.

    Two more nice ideas that were mentioned in the article for Robot :

    a) Error(s) on the page must be displayed via the same object with the same ID and this ID must be the same across all pages of the tested application. If it is really needed to display more than one error object on the page, than those objects must have IDs with the same prefix. The above will make it really simple for you to check in test code whether or not an error was displayed: just check if page.FindAllChildren("id", "error*", <depth>) returns something (and whether or not found objects are visible depending on the tested application). No need for the code like (pseudocode):

    if (page.url.contains("order") and page.find(errorObjectForOrder))

    else if (page.url.contains("checkout") and page.find(someOtherErrorObjectForCheckout))

    else if(...)

     

    b) If you need to check data in a (web) table, it is really cool if every cell of the table has compound id consisting of common prefix (e.g. <tableName>_<ColumnName>_ ) and a suffix that describes data in the given cell. This is especially handy and useful if the cell contains non-textual data that must be verified.

    For example, consider a two-column table that displays the name of a car and car's image. How can you check that, say, for two rows, one for BMW and another for Fiat, images correspond to names?

    But if the cells have IDs like this:

    Cars_BMW_Name | Cars_BMW_BMW_imageSmall60x80.jpg

    Cars_Fiat_Name | Cars_Fiat_FiatscreenshotFromShow.png

    then you definitely will be able to create more simple and reliable test code.

lachapan's avatar
lachapan
Occasional Contributor

Thanks Alex, yeah it's a point we constantly try to make with Developers. We are starting to make inroads with our Development teams.

AlexKaras's avatar
AlexKaras
Champion Level 3
7 years ago

Andy,

 

It is really good if it is possible to ask Development for the things that you need and they consider your requests.

Two more nice ideas that were mentioned in the article for Robot :

a) Error(s) on the page must be displayed via the same object with the same ID and this ID must be the same across all pages of the tested application. If it is really needed to display more than one error object on the page, than those objects must have IDs with the same prefix. The above will make it really simple for you to check in test code whether or not an error was displayed: just check if page.FindAllChildren("id", "error*", <depth>) returns something (and whether or not found objects are visible depending on the tested application). No need for the code like (pseudocode):

if (page.url.contains("order") and page.find(errorObjectForOrder))

else if (page.url.contains("checkout") and page.find(someOtherErrorObjectForCheckout))

else if(...)

 

b) If you need to check data in a (web) table, it is really cool if every cell of the table has compound id consisting of common prefix (e.g. <tableName>_<ColumnName>_ ) and a suffix that describes data in the given cell. This is especially handy and useful if the cell contains non-textual data that must be verified.

For example, consider a two-column table that displays the name of a car and car's image. How can you check that, say, for two rows, one for BMW and another for Fiat, images correspond to names?

But if the cells have IDs like this:

Cars_BMW_Name | Cars_BMW_BMW_imageSmall60x80.jpg

Cars_Fiat_Name | Cars_Fiat_FiatscreenshotFromShow.png

then you definitely will be able to create more simple and reliable test code.