Last Updated: 07 Dec 2014 18:51 by Loc
Velin Koychev
Created on: 04 Feb 2014 15:28
Type: Bug Report
"Wait for visible" random failure with ArgumentException: Tag collection is either empty or has less elements than the element occurrence requested
In a specific customer application, when we use "Wait for visible" test steps, Test Studio randomly fails the test step  with the following exception:

ArtOfTest.Common.Design.Exceptions.VerificationWaitException: Unexpected error while waiting on condition. Error: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> ArtOfTest.WebAii.Exceptions.ExecuteCommandException: ExecuteCommand failed!
InError set by the client. Client Error:
System.ArgumentException: Tag collection is either empty or has less elements than the element occurrence requested. RequestedIndex: '2', ElementLength: '1'

Steps to reproduce and a sample test project are attached in the internal description. 
Posted on: 07 Dec 2014 18:51
So, you guys mean that... "exists" should be checked FIRST.... then other HTML attributes like visible, style, text content should be checked AFTER?
Daniel Djambov
Posted on: 16 Oct 2014 14:42
Telerik: we have just released it ( You can download it from here:
Posted on: 16 Oct 2014 12:49

When will be the release?
Posted on: 03 Oct 2014 11:33
Made my day, thanks!
Daniel Djambov
Posted on: 03 Oct 2014 11:25
Telerik: The issue is fixed and solution will be available in our next product release, planned in October 2014. 
Konstantin Petkov
Posted on: 29 Sep 2014 11:44
Hi All,

Just a quick follow up to my previous comment.

Each action and verification step includes a WaitOnElements property which if turned on does that - waits until the element is available. In addition EnsureStateIsCurrent property performs a refresh of the browser DOM instance the execution operates on.

Upon further investigation (thanks David for the repro!) we figured out the Visible verification (regardless if the role is Wait or just Verification) may not be ready to execute despite those options. Since this depends on previous steps and related commands we can only trap the exception and try again. This proves to work well for those apps we have available to confirm so we are going to commit that once confirmed by QA.

Konstantin Petkov
Posted on: 25 Sep 2014 10:54

Let me first clarify there are two separate problems included here - one is the exists vs. visible verification that has been discussed, and another - a problem of recording of element from frame for the particular customer application. We keep this open yet due to the second problem, which has been put development/QA effort on but needs more testing so that we can make the recording of frame elements reliable as well.

On the wait for exists vs. visible, I think Ryan explained it quite well. Basically in HTML the visibility is just a verification of an element attribute as is any other verification of text, style, etc. If the app is developed to generate the element dynamically, one would need to ensure the element exists first prior to adding verifications over that, which is achieved via "Wait for Exists" step. We shouldn't mess visibility and exists verifications as these are quite different in nature (at least for HTML). Also adding the exists within the visible would hit performance on execution although it won't be needed in the majority of the test cases.

I hope this makes sense to you guys and thank you for the useful discussion!

Posted on: 29 Jun 2014 12:42
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!
Attached Files:
Posted on: 25 Jun 2014 23:09
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.
MarketSharp User
Posted on: 25 Jun 2014 20:25
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.
Posted on: 19 Feb 2014 22:16
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.