Thanks for writing up your experience, this might be useful for others in the future.
Marcin On Mon, Aug 1, 2016 at 8:45 AM, Andrey Hitrin <[email protected]> wrote: > Marcin, thank you a lot for your quick and detailed response! I'm so sorry > I couldn't be as fast as you... > > Your suggestions helped me a lot, and after two or three weeks of hard > work I had finally achieved a 100% stability of our tests using the 0.13.1 > Geb release. This was very great! > > What changes we had to do: > > 1. Add new options to the GebConfig.groovy > > atCheckWaiting = true > baseNavigatorWaiting = true > > 2. Add waitFor steps after closing of new windows (maybe it's needed > because of behavior of SUT). Something like this: > > browser.withNewWindow({addItemButton.click()}) { > ... (setup item and press 'save') > } > waitFor {itemsList.find('td')*.text().contains(itemName)} > > > 3. Add new page object for all dialogs (this advice was really helpful, > thank you!). In order to minimize code changes (we have a LOT of dialogs) > this page object is used be deafult as options.page right in the > overwritten Browser.withNewWindow method (gods bless Groovy > metaprogramming!) Of course, it looks like ugly hack, but we already had to > overwrite this method for some reasons. So this change may be counted as > "small". > > 4. Explicitly define target page for all clicks that cause page refresh: > > someLink.click() > # becomes > someLink.click(AwesomePage) > # or for clicks inside page object methods that do not change the page > someLink.click(this) > > > This change was one of the biggest (since we have a lot of clicks too!). > But at least it improves code readability :) > > 5. We also had to give up using long page lists in the to: content option, > like this: > > class LoginPage extends Page { > static content = { > loginButton(to: [UserPage, SuperUserPage, NoRightsPage, ...] > } > } > > All page objects in this list are checked sequentially, but only one check > could be successful. With 5 pages in the list and 10 seconds waiting in the > GebConfig.groovy (our settings) this means that we have to wait up to > 40-50 seconds after each login until the test continues to work. I've tried > to overwrite the way Geb looks for pages here into something like "run all > checkers simultaneously and wait until one of them succeeds" but had no > success (I didn't try too hard, though). So we've had to explicitly define > expected target page for the login button. > > All this work has been done a few month ago, but I think you're still > interested in feedback. Our experience in working with the new Geb version > shows that it's stable, useful and still rocks. Sadly, we haven't got any > significant improvement in test speed after the transition, but I think the > cause lies in the speed of our SUT. When (for example) 90% of click() time > is server response time and 10% is WebDriver+Geb time, it's hard to see Geb > improvements :) But it doesn't mean these improvements are useless! Thank > you for this work anyway! > > четверг, 7 апреля 2016 г., 15:39:40 UTC+5 пользователь Andrey Hitrin > написал: >> >> Hi! >> >> In our company we have a reasonably large suite of acceptance tests >> (several hundred tests) written in Geb. Currently, we're using *Geb >> 0.10.0*, Selenium 2.46.0 and Firefox (both local and remote). >> >> The problem appears when we try to upgrade our dependencies. Namely, I >> try to upgrade Geb to the newest *0.13.1* without touching other >> dependencies. >> >> It looks like WebDriver starts to act way more eager than before, >> throwing away some previously existing waits. This causes our tests to fail >> in many random places unless we put a lot of *waitFor* into it. For >> example, when working with dialogs: >> >> // Works fine with Geb 0.10.0, but not in the any newer version >> browser.withNewWindow({ someButton.click() }) { >> $('input#title').value(title) >> ... >> } >> >> >> After upgrading to the newer versions this code may fail because >> WebDriver may start to act on the dialog before page actually loads. When I >> put simple *assert !$('body').empty* into the beggining of the window >> closure, it fails randomly (but never fails in Geb 0.10.0). So, in order to >> fix our tests we have to add a lot of waits, like that one: >> >> browser.withNewWindow({ someButton.click() }) { >> waitFor { $('input#title').displayed } // or, for example, >> waitFor{ !$('body').empty } >> $('input#title').value(title) >> ... >> } >> >> But we have *a lot* of dialogs in our system under test, so amount of >> code to change is really large. That's pity. >> >> Situation is a little more strange because I cannot reproduce this >> problem *in virto*. When I just save HTML page of our application and >> run it under Python SimpleHTTPServer, synchronisation issue on the dialog >> disappears. But in our application (Spring web app running under Tomcat) >> such failures appear very frequently. >> >> Seems like we have to stay on 0.10.0 for now, but it's unclear for me >> whether the situation with waits will change in future. It's also unclear >> whether it's a bug of Geb or not. >> >> May I ask you for help? >> > -- > You received this message because you are subscribed to the Google Groups > "Geb User Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/geb-user/d06cee4e-ece3-4662-a494-5ee4b16aac01%40googlegroups.com > <https://groups.google.com/d/msgid/geb-user/d06cee4e-ece3-4662-a494-5ee4b16aac01%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Geb User Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/geb-user/CA%2B52dQQKop0kW1Rdsyz5Xu6gWYEKXdFOVoerqXhL7MeTGhRUFw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
