Ability to Wait Until Web Page Contains or Perform IF Web Page Contains

Hi Zach,

Thanks for creating a feature request. Would you please elaborate on your thoughts where this would give more flexibility than Verify_element or Verify_Text? Given that the functionality already exists, it would be really helpful to understand your point of view on this. Thank you.

Regards.
Subject7 Team

Verify_Element and Verify_Text functions only validate immediately upon the step. Sometimes when alert messages are inconsistent when showing up whether it is 1 second or 3 seconds these commands tend to fail. I know we are able to add intervals and seconds, though it would be much more stable on a script perspective if we were just able to wait until the specific element or text showed up. On the perspective of an IF web page contains, this would allow us to control different work flows easier. If we know sometimes a certain process gives us a pop up, we could say IF the text or element is shown, then follow these certain steps. The only thing closest to that we can do in Sub7 as of today would be to get the GET_WEB_VALUE. This is just a work around, which is honestly quite unstable (if path's change, etc.) and does not provide the end user with as much flexibility. Additionally, we would be able to have steps that could focus on debugging. Please see some examples below. 

IF WEB PAGE CONTAINS - EXAMPLES:

1) -> In this scenario let's say a pricing application, we want to validate that IF the web page contains a specific element after clicking on 'submit quote', however, if it doesn't, we want to assert the flow immediately with a designated user-friendly message.

* In this current scenario we tend to have scripts fail at steps that are not necessarily always at the actual step of failure due to the inability of having more control on what is shown and the steps that follow.

2) -> In this scenario let's say an ERP application, we want to submit a quote, and validate that IF the web page contains 'duplicate expense pop-up' we are able to navigate the proper steps to close the pop-up to continue forward without script failing. 

* In this current scenario we would have to use the GET_WEB_VALUE and set Run Time options to 'Continue on Failure' which is not ideal. This is a pretty unstable solution, and if element changes it can be tricky to get the script back on track. Plus, it adds more time onto the script if it times out at 30 seconds and then skips the step if run time option is continue on failure. 

WAIT UNTIL WEB PAGE CONTAINS - EXAMPLES:

1) -> In this scenario let's say a pricing application, we want to populate some customer information (Customer Name and Customer Group) and wait until the table is auto-populated with data it is auto querying (average lbs shipped, and ship points). However, there is no consistency on how long this might take, it could vary depending on the customers, recent orders, lines on the orders, etc. That being said, if we could wait until web page contains a specific value prior to moving forward this would prevent a lot of failures.

* In this current scenario we would have to add a WAIT of 30 seconds or multiple WAITS which is not ideal, because it can cause scripts to wait significantly longer than really needed. Additionally, sometimes it is hard to pinpoint the actual average wait time of this sort of stuff as it could be very dynamic depending on customer information. Plus, if we do not put long enough waits, then we get script failures for something that shouldn't.

2) -> In this scenario let's say an ERP application, we submit an accounting process, and want to validate to proceed forward with certain steps IF the web page contains 'succeeded' for the process. Or even when the process is completed, that it auto opens a pop-up that allows for a user to input a few more additional fields. Once again, these would not be immediate UI responses, as an accounting process might depend on the business unit, transactions per period, validating transaction discrepancies, etc. 

* In this current scenario we are adding GET_WEB_VALUE functionality and COMPARE or CONTAIN command to validate various messages. This is a short-term solution, and not giving us the most stable results. 

Hi Zach,

Apologies for the delay in response.

When you say Get_Web_Value command fails so you are forced to use Continue on Failure, I am guessing you are not using Boolean option. This option looks for an XPath on your web page and provides either True (where element exists) or False (where element does not exist), but this option never causes the step to fail so you would not have to change the runtime options. Then in the subsequent conditional If, you can use If True > do something and Else > do something else.

Verify_Element and Verify_Text can be made to work dynamically with Attempts and Intervals rather than using Wait and the only thing that can cause these commands to fail is below:

A. The element or text is still not found after waiting all attempts and intervals (also affected by locator timeout period)
B. Step Timeout, which can be fixed under Administration > Account Preferences > Timeouts. This feature is available to prevent a step from being indefinitely stuck, so it would eventually time out. 

Notes:

1. If Verify_Element or Verify_Text find the element/text, they will not take as much time as Wait, because they automatically be marked as Pass, but only if there are enough attempts and intervals to allow them to keep looking, but not longer than the Step Timeout duration.

2. By using what we have described above, then there is no need to use Compare or Contains because these commands:

A. Pass if the element/text exists (While Exists option is enabled) and fail if opposite

B. Pass if the element/text does not exist (While Does not exist option is enabled) and fail if opposite

Hope this helps. Please let us know if you have any thoughts/ideas.

Regards,
Subject7 Team

Hi Joseph, thank you for your post. I am aware of the majority of the above options. I do appreciate you mentioning the option of boolean for the GET_WEB_VALUE function as well. I had totally forgot we are able to simply get a true or false relative if that element was found or not. As these are all relatively decent options, I would say it still is not the most reasonable in our eyes. In a lot of applications that we are testing, it is not the most straight forward knowing 'when' an error will show up or a process is complete. Yes, we could do the GET_WEB_VALUE and then run IFs, but that is a lot of steps if we are having to do that consistently throughout the entire automation. The reasoning why I had suggested the other two options were to help simplify this process. Additionally, what if you are trying to wait for a process to complete and the error takings a long time, now we have a long wait. But the next script maybe it shows up way faster, now you are stuck running through all the intervals and attempts regardless of the actual time. This just will add significant script time, compared to the functions I had mentioned that allow for more dynamic behavior. 

Hi Zach,

Thanks for sharing your thoughts. We understand your concern when it comes to complexity, we will discuss this and find the best approach.

Regarding waiting for a process to complete, the general approach is that any command will wait until the element/text appears on screen, then after a period of time some action will be taken (either pass or fail). How much time is being spent is controlled by the parameters on Verify_Text and Verify_Element commands, hence we suggested to use them rather than using a predetermined value in Wait command which will always take the same amount of time. This is already a dynamic process in the sense that the duration of the command depends on the amount of time the app displays the element/text before the command sends the output. 

The below snippet can be pasted in Advanced View and tested where we show that waiting for a static amount of 15 seconds can result in a pass, but doing the same in Verify_Element can take 10-11 seconds:

WEB GOTO_URL "https://123timer.com/10-second" HALT ON ERROR
STEP_GROUP "Static 15 second Wait" HALT ON ERROR { 
 WEB CLICK TARGET ELEMENT XPATH "(//text()[contains(.,'Start')]/ancestor::div)[8]" ALIAS "" HALT ON ERROR 
 WAIT 15 HALT ON ERROR 
 WEB VERIFY EXISTS TARGET ELEMENT XPATH "//div[contains(text(),'Finish')]" ALIAS "" INTERVALS 10 ATTEMPTS 2 HALT ON ERROR
 WEB CLICK TARGET ELEMENT XPATH "//button[contains(text(),'Okay')]" ALIAS "" HALT ON ERROR 
} 
STEP_GROUP "Verify_Element Dynamic Wait" HALT ON ERROR { 
 WEB CLICK TARGET ELEMENT XPATH "(//text()[contains(.,'Start')]/ancestor::div)[8]" ALIAS "" HALT ON ERROR 
 WEB VERIFY EXISTS TARGET ELEMENT XPATH "//div[contains(text(),'Finish')]" ALIAS "" INTERVALS 5 ATTEMPTS 3 HALT ON ERROR
 WEB CLICK TARGET ELEMENT XPATH "//button[contains(text(),'Okay')]" ALIAS "" HALT ON ERROR 
}

Regards,
Subject7 Team

Thank you, Joseph, we will continue to test these new suggestions out in our current and new scripts we create. Thank you for your time and effort.