Actually this doesn't solve our issues.... Here are the recent 2 use cases I
fixed in VersionTest (with Sergiu's help).
Use case 1:
==========
hmmm actually I don't see how this would solve the race issue found in
VersionTest when clicking on the history tab:
- page loads (doxextra.vm)
- register: Event.observe($("${extraAnchor}link"), "click",
function(){ XWiki.displayDocExtra("${extraAnchor}", "${extraTemplate}", false);
}, false);
- register document.observe("dom:loaded", extraInit, false); is
registered
Sometimes the click event handler is called before the dom:loaded one.
But we can consider this a bug in our code (see
http://jira.xwiki.org/jira/browse/XWIKI-6688)
Use case 2:
==========
When we rollback there's a confirmation box and when accepted there's a client
side redirect and the page is reloaded. The issue is that we need to wait for
the new page to have finished loading as otherwise the next test command can
execute on the page before the reload. In the VersionTest case it was clicking
on the history tab before the refresh and thus when the new page was reloaded,
the comments tab was active and not the history one.
The solution proposed in the mail below wouldn't solve this AFAIK.
So back to square one...
-Vincent
On Jun 10, 2011, at 8:53 AM, Vincent Massol wrote:
> Hi guys,
>
> I asked the following on the webdriver forum:
> https://groups.google.com/d/topic/webdriver/5WdDJsiyAzc/discussion
>
> Kristian mailed me the following below which I find interesting.
>
> WDYT? Since I'm not know a prototype expert could someone knowledgable tell
> me if this can be done? (I've found
> http://www.prototypejs.org/api/ajax/responders but not sure if it's enough
> for us).
>
> Thanks
> -Vincent
>
> Begin forwarded message:
>
>> From: krosenvold <[email protected]>
>> Date: June 9, 2011 8:56:20 PM GMT+02:00
>> To: Vincent Massol <[email protected]>
>> Subject: Re: Re : Re: How to know if a page has been reloaded after some
>> ajax refresh
>>
>> I have generally solved this problem by instrumenting
>> the application javascript ever so slightly, by exploiting
>> the following known facts:
>>
>> Any immediate code executed by "onClick" handlers is
>> guaranteed to be finished before control is returned to
>> the client code.
>>
>> Most popular frameworks allow you to add a global hook
>> that allows you to increment a counter for every request
>> that is started. If you add one hook that increments on
>> start and one that increments on ajax request termination,
>> your test can basically wait for a given javascript variable
>> to become 0.
>>
>> The nice thing about this is that if you do fancy visuals
>> (sliding or fading stuff that you actually intend to click in your
>> tests),
>> you can intercept "onEffectStart" and "onEffectEnd" and
>> increment/decrement the same counter.
>>
>> And if you chain this properly, you can have a client-side added
>> "onComplete" ajax handler that starts a sliding visual effect and
>> the counter will be guaranteed to not reach 0 before the effect is
>> finished.
>>
>> So our page object base class has a waitForAllEffectsToFinish
>> method that we actually surround to all calls to click. Our tests
>> went to flaky to 100% rock solid after we did this.
>>
>> Btw, you must use a counter - this won't work well enough with
>> a boolean.
>>
>> Kristian
>>
>>
>>
>>
>>
>
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
