[QA] waiting for DOM changes

[Chris McMahon]

One more example, in this case we want to test that the view of the page
re-organizes itself in less than one second, and we use sleep() to do it:

https://github.com/wikimedia/mediawiki-extensions-Flow/blob/master/tests/browser/features/collapse.feature
(line
8)
https://github.com/wikimedia/mediawiki-extensions-Flow/blob/master/tests/browser/features/step_definitions/collapse_steps.rb
(line
13).

In this case I would suggest that using sleep() is the right thing to do.
-Chris


On Fri, Dec 20, 2013 at 3:33 PM, Chris McMahon <cmcmahon at wikimedia.org>wrote:

>
> A couple of examples:
>
> Here the test for sidebars waits for the expand/collapse state to settle
> as the page loads:
>
> Then(/^Interaction section should be collapsed$/) do
>   on(RandomPage) do |page|
>     page.community_portal_element.element.wait_while_present
>     page.community_portal_element.should_not be_visible
>   end
> end
>
> 'wait_while_present' stops the test from moving on while the element is
> present on the page.
>
> Here the AFT test waits until the text "Thanks" appears on the page.  At
> that point a certain link and text should also be available:
>
> page.wait_until(10) do
>       page.text.include? "Thanks!"
>     end
>     page.text.should include "Your post can be viewed on this feedback
> page."
>
>
>
>
>
>
> On Fri, Dec 20, 2013 at 3:12 PM, Amir E. Aharoni <
> amir.aharoni at mail.huji.ac.il> wrote:
>
>> Hallo,
>>
>> TL;DR:
>> What is the most robust way to get JavaScript to tell Selenium that some
>> change to the DOM was made and that the testing script can go on with the
>> checks?
>>
>> In detail:
>> The Language Engineering team has been developing a new special page for
>> the Translate extension in the last few weeks, and with Željko's help we
>> managed to do it quite well in test-driven development style.
>>
>> One notable issue that we encountered during the development of tests for
>> it is testing that new elements appeared on the screen or initially
>> existing elements disappeared from the screen. This is made harder by
>> several factors:
>>
>> 1. WebDriver scripts working faster than JavaScript and making the test
>> before JavaScript finishes something. This is especially frequent with AJAX
>> API calls, but such a race condition can happen even without that.
>>
>> 2. An element can be accessed in the beginning of a scenario or even a
>> single step, disappear from the screen, then be recreated with the same
>> class. Even though it has the same class, it's a different object, so it
>> gets Selenium confused.
>>
>> Željko initially suggested using Watir::Wait and using as a condition
>> some expected change in the DOM, for example a change in the count of some
>> elements. It worked for some time, but it cannot always be expected and the
>> two problems mentioned above came back to bite us and got us stuck thinking
>> how to resolve them in a more robust way.
>>
>> The latest thing we came up with is setting a global variable in the
>> JavaScript code and then doing something like
>> Watir::Wait.while { @browser.execute_script "return window.updatingDom" }
>>
>> You can see an example in
>> https://gerrit.wikimedia.org/r/#/c/102943/
>> (Not yet merged - review comments are welcome.)
>>
>> What are your thoughts about it? Is it OK to use such a variable or is
>> there a better pattern? Is it OK to make it a property of the window
>> object? Are there any suggested naming patterns?
>>
>> Thanks!
>>
>> --
>> Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
>> http://aharoni.wordpress.com
>> ‪“We're living in pieces,
>> I want to live in peace.” – T. Moore‬
>>
>> _______________________________________________
>> QA mailing list
>> QA at lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/qa
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/qa/attachments/20131220/16370788/attachment-0001.html>