Hi Brian,

I don't think there's any good reason for some to be hard-coded to 5000, or other similar numbers of milliseconds. Feel free to flip them to use a constant and check that in, and then locally change the value of the constant.

Thanks,
Josh

For sure those should be a single constant instead of numeric literals - duplicating literals like that is generally evil, for reasons such as the one we face now.

But I didn't pose the question very well - I'm wondering if the name WAIT_FOR_GWT has any particular significance. It's only that I don't want to propogate a misnomer - is GWT actually involved in everything that we wait on? Or do I want a second constant WAIT_DEFAULT? I don't know the code well enough to say and wouldn't want to make a mess of it. So which of the following best serves the code and its maintainers?

A Use WAIT_FOR_GWT everywhere we do now, and where ever we had a numeric literal timeout value of 5000
B Introduce another constant WAIT_DEFAULT, leave uses of WAIT_FOR_GWT alone as it's a special case
C Use WAIT_DEFAULT everywere, WAIT_FOR_GWT is a misnomer

Thanks,

Brian

Hi Brian,

I think there are two common kinds of waits in the tests.

The first is a longer wait, specified by the defaultWaitForPage constant, that is how long we'll wait for a full page to come back from the server.

The second is a shorter, sometimes specified by WAIT_FOR_GWT and sometimes as a hard-coded constant. It's how long we wait for the page to respond to an event that won't change the URL to change. For example, waiting for the page to respond to a button click inside of a GWT action that will modify the DOM.

WAIT_FOR_GWT should probably be renamed to something like WAIT_FOR_JAVASCRIPT and used in more places - GWT pages, ExtJS pages, plain JavaScript, etc. I don't think it's useful to distinguish between the specific flavor of JavaScript that's running.

Thanks,
Josh

OK, modified plan C it is: replace WAIT_FOR_GWT and the hardcoded 5000 values with WAIT_FOR_JAVASCRIPT.