Forum Discussion

carlesrc's avatar
carlesrc
Occasional Contributor
4 years ago

Scripts succeeds only after running a first time

Wonder if anybody else has experienced the same problem:

(Running TC Version: 14.71.275.7 x64 in a Win 10 Virtual Machine)

 

  1. - Testing a web based application. Web server in the same machine as TC
  2. - TC is able to load the page, click in some elements, however, when it gets to a a button is it unable to find it
    1. Tested object:
      Sys.Browser("chrome").Page("https://standalone/Web/#Settings/Teams").FindElement("//iframe[@id='Teams']").FindElement("//input[@value='Add Standard User']")
  3. The screenshot shows the correct page, and the elements is displayed, however TC is unable to find it,
  4. - Close the browser and run the TC script again
  5. - Scripts succeeds
  6. - Execute a iisreset
  7. - Repeat from the beginning, script fails

So, it looks like the object is not fully loaded into memory,

 

I have tried to add delays and reload the page to not avail.

 

Any suggestion or indication on how to solve this problem?

 

Thanks in advance,

 

Carles Roch-Cunill

4 Replies

Sort By
  • tphillips's avatar
    tphillips
    Frequent Contributor
    4 years ago

    What happens if you add a delay before trying to interact with the object?

    What error message does it give when it fails?

    Is the element identification information the same every time you visit the page?

    • carlesrc's avatar
      carlesrc
      Occasional Contributor
      4 years ago

      Hello,

       

      Thanks for the reply.

       

      - If I add a wait time I get the same results: unable to find object. The screenshot associated to this step, however, shows clearly the element (a button)

      - The error message is unable to find element

      - It is a static element. It does not change and there is no other element with the same properties that can 'confuse' TC. It is simply a button that when clicked shows a new (static) form.

      - The failure occurs always at the same element.

       

      I have been able to bypass this problem changing the way the element is identified

      page.FindElement("//div[@id='secondBannerContent']/div/div/div[2]")
       
      instead of 
      page.FindElement("//iframe[@id='Teams']").FindElement("//input[@value='Add Standard User']")
       
      This last locator was the one that TC wrote when converting my original (recorded) keyword test to script.
      • AlexKaras's avatar
        AlexKaras
        Champion Level 3
        4 years ago

        Hi,

         

        It is good to know that you've managed to solve the problem.

        Several notes:

        -- As TestComplete can identify the button using 'div' syntax, for me it sounds like that the original locator does not work anymore. Use browser's Developer Tools or TestComplete's Object Browser to double check that the button still can be identified as "//input[@value='Add Standard User']". Note possible leading/trailing white characters.

        -- I am not XPath expert and I think that the search line like this (FindElement("//iframe[@id='Teams']").FindElement("//input[@value='Add Standard User']")) will work (almost?) in all cases, but I think that it is not optimal in terms of performance as it searches for every element from the root of DOM model. My preference is to search not from the root, but from the parent container object. I.e.: FindElement("//iframe[@id='Teams']").FindElement(".//input[@value='Add Standard User']"). Note the dot before //input. Though this note is just for the record.

         

        > It is a static element. [...] shows a new (static) form.

        Please define what is 'static' in this case. Web element can be considered to be static only if it is obtained from the server within page source and constantly exists in page markup. It may be visible or not but it must exist and must be not (re)created via script. If the element is downloaded asynchronously and then inserted into DOM or generated via script, then such element is dynamic. Even if it has the same id every time it is (re)generated. In such case you are just lucky because you are dealing with the application that was created with testability in mind.

         

        > The screenshot associated to this step, however, shows clearly the element (a button)

        Error message is of higher priority and level of trust. Just because it takes some time to take a screenshot and post error message to test log when the element is not found. And the time it takes might be enough for the element to be inserted in the DOM and to be rendered on screen.

         

        The bottom line:

        If the element cannot be found this is usually because of either incorrect/changed locator or the element to be dynamic and TestComplete is not instructed to wait for it.

         

        P.S. I would also recommend to read this my post https://community.smartbear.com/t5/TestComplete-General-Discussions/Unable-to-handle-the-error-using-the-script-quot-Unable-to-find/m-p/170363/highlight/true#M31588 to get the understanding about how TestComplete addresses sought for objects.

         

  • AlexKaras's avatar
    AlexKaras
    Champion Level 3
    4 years ago

    Hi Carles,

     

    > TC is able to load the page, click in some elements [...]

    a) It is a good practice to use .Wait() method after clicking on some element that requests server to let TestComplete to wait until the page is loaded from the server;

    b) Consider to use the .WaitElement() method instead of the .FindElement() one.