So, you guys mean that... "exists" should be checked FIRST.... then other HTML attributes like visible, style, text content should be checked AFTER?

Hi,

When will be the release?

Made my day, thanks!

Ryan - it is not enough to test for existence in our application, it is common for sections of the page to be hidden.  Furthermore, it isn't easy/practical for the script developer to know for each and every element if exist is good enough, so we often resort to wait for visible and it isn't uncommon to hit this error or others like it (COM ERROR and NullReference).

We wrote a wrapper function that catches these errors and tries again.  See attached - this is a simplified version of what we use, so it should be tested.

@Sarah - this method can be placed in a helper .dll file that you reference in your project.  You then make the call with something that looks like this:

TestStudioHelpers.WaitForUtilities.waitForVisibleWrapped(this, ()=>Pages.PegaDesignerStudio.clipboard);

The wrapper isn't ideal though - we don't like using coded steps as it makes test maintenance difficult.  For example, refactoring the element repository will result in compilation errors.

BTW, I suspect the root of the problem here is that the section where the element is located is somehow reloaded via ajax or the like and so the element is at first located, then the subsequent operation to test for visible chokes because the DOM moved.

Hope this helps!

There is a common misconception about visibility. Visibility is just one of an html element's many attributes. It is no different than if you were verifying text on the element. If an element has not been loaded yet, it will tell you that it doesn't exist rather than telling you that your verification failed because it wasn't an attribute mismatch, the actual element wasn't there!

Wait for exist doesn't break if the page is still being loaded because the element is expected to be null. The visibility check assumes that it has already been created and that is where your error is coming from.

In short, Wait for Exist is what you want to use if your verification is running before your element is created. Even with that though, I admit I've had difficulties with elements not being found! Putting a half second wait AFTER the element exists has been the most effective solution I have found.

I am experiencing the same issue, and it is making me crazy.  It was suggested to add WaitForExists step for that particular element or you can also add an Execution Delay (3000ms).  Since these errors occur randomly, where do I add the WaitForExists steps and Execution Delays?  If I add them to the steps that fail on one test run, I will simply receive more of these errors on other steps on future runs.  I can't add them to every test step, that is not practical.  Please advise when this will be fixed in the future, as it renders the scheduling or running test lists useless.  Currently, tests need to be 'watched' and re-run when this error occurs.  

David, Would you be able to send me an example of the helper method?  I am not a developer, but would like to have one of our developers help me incorporate this.

We have seen this a lot in the past - so much that we wrote a helper method which catches the exception and tries again, almost always successful in the retry.  This was a sore spot for stability - tests would fail randomly with this issue, very discouraging.

The issues would seem to be timing related, which is also difficult because the wait for visible steps are generally put in to help pace the timing.  Guessing that there is some sort of asynchronous communication with the server that is altering the DOM while the browser still reports "ready".

Recently we have achieved much more stable tests with a changes to our product that help the script know that it is safe to continue - we put a div with our own flag at the root of the DOM that contains some state information.  When we take an action, we call a method that inspects the element and waits for communication to quiesce, then continues.  This has been a life saver, it is now much easier to achieve test stability.

Long comment, but this issue is likely to do with timing - getting timing right is critical to test sanity, wish there were some way to avoid the custom code to signal that it is safe for script to continue.