smoothing waitFor's rough edges: which way forward?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

smoothing waitFor's rough edges: which way forward?

Nelson Sproul

Currently when we wait for some JavaScript condition to be true, if an exception is thrown during the JavaScript evaluation used to determine whether that condition is true, this exception is ignored in selenium-commandhandlers.js:

 

                            testLoop.waitForCondition = function () {

                                    try {

                                                    return function.call(seleniumApi, target, value).isTrue;

                                                } catch (e) {

                                                            // Treat exceptions as meaning the condition is not yet met.

                                                            // Useful, for example, for waitForValue when the element has

                                                            // not even been created yet.

                                                            // TODO: possibly should rethrow some types of exception.

                                                            return false;

                                                }

                            };

 

Obviously this code has the effect of suppressing the reporting of unexpected problems.  One possible improvement would be to check the exception to see if it is a SeleniumError, and if it isn't, re-throw:

 

                                                            if (!e.isSeleniumError) {

                                                                        throw e;

                                                            }

 

It would be nice if there were a way to get rid of the try/catch altogether, and thereby be sure that we are never suppressing interesting information.  There are several alternative approaches to this problem:

 

1. Write waitFor* routines for the various specific conditions that we wait for.  Within these routines, only suppress exceptions which arise from well understood conditions, e.g., waitForAlert() would only suppress the exception which arises from getAlert() when there is no alert to be gotten.

 

2. Change the behavior of get* so that in the case where the sought-after item does not exist, no exception is thrown, and we simply return null.  This would lead to an API which is more in keeping with how things are normally done in the various client-side languages.  The drawbacks are that it would

 

            a. complicate the communication mechanism on the wire

            b. introduce risk on the client-side by introducing -- some of the time -- null references.  Naturally we prefer code which works exactly the same way every time, or else throws.

            c. change the current behavior, possibly breaking existing tests

 

3. Write is* functions for all the things currently accessed using get* functions.  The is* functions would simply returning true or false to reflect their state; any exception would be unexpected, and therefore not caught.  Our instinct is that this approach would provide the best combination of cleanliness and ease of implementation.  I suppose it would also make sense to also automatically generate corresponding waitFor* and store* routines.

 

Do you have any thoughts concerning these or other possible approaches?

 

n

 

p.s.: Also, what happens to waitForAlert(foo)?  This is kind-of a silly command, since the user probably really means to "waitForAlertPresent(); assertAlert(foo);".  Currently, if there is alert which has text different from what is expected, this is ignored until the timeout, which I think is likely not the behavior we want.  I would like to change the meaning of this command to be the following:

 

            function waitForAlert(text) {

                        wait until timeout or there is an alert X

                        if timed out {

                                    Assert.fail ΄there was no alert"

                        }

                        if X.text != text {

                                    Assert.fail ΄there was an alert, but its text was not what we expected"

                        }

            }

 

 

Nelson Sproul
Sr. Software Engineer
Phone: 415.399.7125
[hidden email]

BEA Systems, Inc.
500 Sansome St.
San Francisco, CA 94111
www.bea.com

 

Reply | Threaded
Open this post in threaded view
|

Re: smoothing waitFor's rough edges: which way forward?

R-24
> Currently when we wait for some JavaScript condition
> to be true, if an exception is thrown during the
> JavaScript evaluation used to determine whether that
> condition is true, this exception is ignored in
> selenium-commandhandlers.js:

I agree that this is not ideal, but could we be careful that whatever alternative is implemented that it can be used even when a new page is being loaded?

>  
> p.s.: Also, what happens to waitForAlert(foo)?  This
> is kind-of a silly command, since the user probably
> really means to "waitForAlertPresent();
> assertAlert(foo);".  Currently, if there is alert
> which has text different from what is expected, this
> is ignored until the timeout, which I think is likely
> not the behavior we want.  I would like to change the
> meaning of this command to be the following:
>

How about supporting a waitForAlertPresent command that could be followed by a storeAlert or assertAlert command?

Cheers,
David
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.openqa.org/thread.jspa?threadID=1908&messageID=5419#5419

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]