Hi Martin, The issues you describe in your email are one of the reasons I avoid using implicit waiting (using the wait content option) myself and tend to be explicit about when to wait for things to happen. The way I write tests nowadays is to wait after every asynchronous action (be it loading a page where ajax calls are executed as part of the page load or interacting with an element which triggers ajax calls) for the page state to settle (asynchronous action to complete) before I move on to the next step in the test. I hide all of the waiting in page at checkers and page/module methods so that it does leak into the tests and also does not require other authors of tests to know what they need to wait for as long as they use existing pages and modules. Another benefit of doing it this way is that you are essentially writing tests as if the tested content was synchronous which makes it easier to understand and less prone to mistakes of forgetting to wait for something.
So in your case, I'd wait after whatever that triggers the button to appear happens to complete and wrap it in a page/module method or an at checker if it happens as part of page load. That way you won't need to use the wait content option and you will be able to call any methods on your button without having to wait before doing so. > Instead of 'wait: true', I could f.e. mention an other piece of content as an element to wait for (instead of a time duration) Btw, this is supported, see http://www.gebish.org/manual/current/#content-dsl-wait-condition. On Mon, May 6, 2019 at 12:26 PM <[email protected]> wrote: > Hi all, > > I'm wondering how other people deal with the following scenario / what the > best way for it is in Geb. > Perhaps there exists some functionality already that I don't know of, > perhaps more people run into this issue and we can add some functionality > to geb. > > tldr: how do you optimally deal with* !element_x.displayed* cases. >> Especially when you prefer a wait:true for every action other than >> !displayed on that element/content > > > Sample scenario > - I have a button > - For some tests I want to click that button, in general, it's nice to > define 'wait: true' so that it waits for that button to appear before > pressing it. > (because I won't want to describe everything in my POM or because the > button is dynamically loaded) > - For some tests, I want to make sure that button is not displayed > > Problem: > - I don't want to wait the full default timeout duration to assess that > the button in fact, did not show up. But I also don't want to put an > arbitrary '2 seconds' on it either, it's also too slow and maybe on some CI > tooling it can actually take those 2 seconds to load causing tests that > randomly succeed or fail > - I want to make the tests as fast as possible. To do this, generally, I > wait for some other element that should be displayed at the same time as > the element in question, then I usually do: !*element_x.displayed *with > wait time 0. > But: I don't want to define that (geb) content twice, once with wait: > true, once with wait: false (or wait: 2) > > > Possible solutions I've thought of: > - Would be nice to be able to manually specify a specific wait time inside > the tests when using a geb module's content. > So f.e.: for that element, when declaring it in its geb module's content, > the (default) wait time is set to true. But when calling that content from > inside the test, I can set a specific wait time of 0 > > - Instead of 'wait: true', I could f.e. mention an other piece of content > as an element to wait for (instead of a time duration). I can do this when > I know that an element is loaded at the same time as that other piece of > content. > > Example: Let's say I have button1 and button2, they're both dynamically > loaded at the same time but button 2 should only display when the user > .f.e. has admin rights, then I can link button2's 'waiting time' to button1. > When I do f.e. in my test: *!button2.displayed* it can automatically > wait for button1 to appear, then it can verify whether button2 is displayed > as well, and, if not, automatically throw an exception > > -- > 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/a219b54d-6feb-449f-b75a-ae07e5b7f7fa%40googlegroups.com > <https://groups.google.com/d/msgid/geb-user/a219b54d-6feb-449f-b75a-ae07e5b7f7fa%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%2B52dQSZ2DR9hBdDu3%3DUHg%3DPutO8Ys9HgLbrSK%3Dq_SXaNKck2Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
