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 <[email protected]>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 < > [email protected]> 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 >> [email protected] >> https://lists.wikimedia.org/mailman/listinfo/qa >> >> >
_______________________________________________ QA mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/qa
