if waitforexists

Hi Jared,

I recorded a sample project against www.bing.com, which uses a Wait For Exists step, against an element that exists on the page. The observed behavior is that the test executes the steps in the IF block, because the validation passes.

I am not sure if that matches the scenario that you have and I will appreciate, if you can elaborate more on that. In addition to that, please share a sample project or test that illustrates the issue.

Thank you for sharing your feedback about the conditional If...Else step. To be frank, we do no plan to separate the If...Else block, because it might lead to confusion with some users. It has been designed in this way and changing the UI might have negative effect on the usability. I understand that you don't use the Else block so often and for now, you have to ignore it. I am sorry for the caused inconvenience.

Please do not hesitate to contact us again, if you need further assistance.

Regards,
Plamen Mitrev
Progress Telerik

Thank you for your response Plamen. I loaded up your example, but unfortunately, this does not help me. 

I already understand how to set up a WaitForElement condition codelessly; but doing it codelessly is very clunky to set up, and results in having the empty else branch that will never execute, as well as an extra waitforelement statement that also never executes (see screenshot). I find to be dismaying that If I have 5 codeless conditionals it will result in 10 lines of needless clutter, including several empty ‘else’ branches. 

I am shocked to learn this is a design decision, and I won’t comment as to what I think of that. But as it is the case, I would like to perform conditionals in code when possible, which leads me to my next question:

I cannot use in code: 

If (Waitforelement)
{
Perform validation on element 
}

Waitforelement is a void method, and the ‘if statement’ takes a Boolean so this will not work.

I would like to know these things specifically. 

1.    How should I set up the above conditional?


2.    How do I tell a coded step that it is supposed to record a ‘failure’ vs to ‘’ignore’ (move on without recording a failure?) 
In one of the fields I am working on, depending on what is selected, an extra box may pop up. I want to check if the extra box popped up, and if it did, I want to enter a value in it. But if I use a validation to check for it and it is not there, the step may record a failure when I don’t want it to. 

(it could be based off the value of the previous box to know whether the new box is supposed to be there and check for it, but for the sake of this question pretend I must check if the new box exists without knowing that.)

To restate: How do I prevent the coded step from ‘failing’ in the first place as opposed to ‘continuing on failure’.

3.    How do I use separate validations within a single coded step. Forinstance, if I have a coded step, and I want to check, within this single coded step, the following conditions:
* if the inner text of textbox1 is more than 20 characters, I want the step to fail with the message “Failure: More than 20 characters”.
* if the inner text of textbox1 has the letter ‘A’, I want the step to fail with the message “Failure: Contains the letter ‘A’”.
* if the inner text of textbox1 has numbers, I want the step to fail with the message “Failure: Contains Numbers”

Hello Jared,

Thank you for sharing more details about the test scenario that you want to automate. I will be happy to help you optimize those and find the best approach possible.

I understand that the test scenario that you want to automate needs to perform or skip some steps based on a condition and you are not interested in the Else block. Unfortunately, you can't hide or remove the Else block, but the extra "WaitForElement" step can be deleted. Once you add it as a condition in the If statement, you can go ahead and delete the step. If you need to make any changes to the condition afterwards, you can do it from the Properties pane, under Verification (see verificationChanges.png).

Please find more details, on the topics that concern you, below.

1. There is a specific to using a coded step against an element that does not exist on the page. The main issue with that approach is that all actions and verifications in code use either the Pages class to get the element, or the Find class. In both cases if the element does not exist in the DOM tree, that step will throw an exception "Element not found" and the action or validation doesn't happen. This is handled differently in the recorded steps and makes it possible to use WaitForElement as condition.
   
   I am not familiar with the application under test and the exact test scenario, so my next suggestion can be totally off. You can use another condition, like the value of certain dropdown control, where you know what kind of validations and actions are expected. If you can share more details and screenshots I will try to advise you further on how you could optimize the test.
   
   
2. There are different types of failure in code and in the recorded steps. When the element does not exist on the page, any actions and verifications against it will throw an "Element not found" exception. As we discussed above, this is not true for the WaitForExists step in the codeless approach. You need to avoid actions against elements that do not exist in the DOM in coded steps and handle this scenario with special conditions.
   
   Another common failure is when the expected result does not match the actual result or value. I this case it is expected to fail the test, because it does not match the requirements and initial design of the test scenario.
   
   
3. You can use different HTML Asserts to verify anything in the application under test. Those methods come with the option to add your own message, which will appear in the execution log and the failure details as well. You can have multiple verifications in the same method and coded step. Please keep in mind that the test will fail after the first failed Assert.

I hope that you will find the above information helpful. I remain available to continue our discussion and find the best possible solution to the test scenario at hand. Please excuse me, if I have misinterpreted or misunderstood anything from your previous messages.

Thank you for your understanding and cooperation.

Regards,
Plamen Mitrev
Progress Telerik