<div dir="ltr"><div><br></div><div>One more example from the Flow tests, I had forgotten about this one: </div><div><br></div><div>This step waits for the spinner to disappear and then checks that the element has some text: </div>
<div><br></div><div><div>Then(/^the saved topic body should contain (.+)$/) do |edited_post|</div><div>  on(FlowPage) do |page|</div><div>    page.small_spinner_element.when_not_present</div><div>    page.topic_post.should match(edited_post + @random_string)</div>
<div>  end</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Dec 20, 2013 at 3:12 PM, Amir E. Aharoni <span dir="ltr"><<a href="mailto:amir.aharoni@mail.huji.ac.il" target="_blank">amir.aharoni@mail.huji.ac.il</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="rtl"><div dir="ltr">Hallo,<br><br></div><div dir="ltr">TL;DR:<br>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?<br>


</div><div dir="ltr"><br></div><div dir="ltr">In detail:<br></div><div dir="ltr">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.<br>


<br></div><div dir="ltr">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:<br>


<br></div><div dir="ltr">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.<br>


<br></div><div dir="ltr">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.<br>


<br>Ž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.<br>


<br></div><div dir="ltr">The latest thing we came up with is setting a global variable in the JavaScript code and then doing something like<br>Watir::Wait.while { @browser.execute_script "return window.updatingDom" }<br>


<br>You can see an example in<br><a href="https://gerrit.wikimedia.org/r/#/c/102943/" target="_blank">https://gerrit.wikimedia.org/r/#/c/102943/</a><br></div><div dir="ltr">(Not yet merged - review comments are welcome.)<br>
</div><div dir="ltr">

<br></div><div dir="ltr">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?<br><br>


</div><div dir="ltr">Thanks!<br></div><div><div><br>--<br>Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי<br><a href="http://aharoni.wordpress.com" target="_blank">http://aharoni.wordpress.com</a><br>‪“We're living in pieces,<br>


I want to live in peace.” – T. Moore‬</div>
</div></div>
<br>_______________________________________________<br>
QA mailing list<br>
<a href="mailto:QA@lists.wikimedia.org">QA@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/qa" target="_blank">https://lists.wikimedia.org/mailman/listinfo/qa</a><br>
<br></blockquote></div><br></div>