Verifying some elements are not displayed

[martind...@gmail.com]

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

[Alexander Kriegisch]

Would it be asking too much to write 

button1.displayed && !button2.displayed

-- 
Alexander Kriegisch

-------- Ursprüngliche Nachricht --------

Von: martind...@gmail.com

Datum: 06.05.19 18:26 (GMT+07:00)

An: Geb User Mailing List <geb-...@googlegroups.com>

Betreff: [geb-user] Verifying some elements are not displayed

--
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 geb-user+u...@googlegroups.com.
To post to this group, send email to geb-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/geb-user/a219b54d-6feb-449f-b75a-ae07e5b7f7fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[martind...@gmail.com]

No it wouldn't, but that statement would take your standard waiting timeout time to complete right?

Unless you specify 

button1{wait:false}

so you end up with

button1{wait: true}
button1_no_wait{wait: false}

or something similar if you also want to use button1 for anything that requires waiting

Or am I missing something?

To unsubscribe from this group and stop receiving emails from it, send an email to geb-...@googlegroups.com.

[Marcin Erdmann]

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.

--

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 geb-user+u...@googlegroups.com.

[Alexander Kriegisch]

Why do you need button1 twice? Some thoughts:

• Assuming that button1 is always checked for visibility (no negative check), you can always wait for button1 without waiting for button2 if you make sure you always check for button2 (in)visibility after button1.
• OTOH, if you want the button2 check to be independent of button1 and you don't wait for button2 in the negative case, the test would pass even if button2 appears, just because you didn't wait for it. So then it would be better to always wait, depending on your test design. Testing for invisibility of asynchronously loaded page elements is always problematic because without waiting the test would pass too quickly and falsely!
• If you want to make your pages more test-friendly, you could always replace invisible elements by other elements (which do not eat screen space but are part of the DOM and accessible by your tests) and check explicitly for the existence of those (also waiting for them to appear, just like for regular elements). This way you always check for existing elements and do not speculate about non-existing ones. The only corner case remaining there would be that your application accidentally displays both the real and the marker element at the same time, in which case you would end up waiting for an invisible element. How far do you want to go there?

Having said that, in the meantime Marcin explained a better approach to handle waiting in general (putting it into at checkers and modules/pages and waiting explicitly).

--
Alexander Kriegisch
https://scrum-master.de

To unsubscribe from this group and stop receiving emails from it, send an email to geb-user+u...@googlegroups.com.

To post to this group, send email to geb-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/geb-user/7da8d5e3-9845-4d7e-bbea-ed816db54e92%40googlegroups.com.

[Marcin Erdmann]

On Wed, May 8, 2019 at 3:32 AM Alexander Kriegisch <alex...@kriegisch.name> wrote:

• (...) Testing for invisibility of asynchronously loaded page elements is always problematic because without waiting the test would pass too quickly and falsely!

Very true!

[J. David Beutel]

I put handlers on the JQuery ajax events to increment counter attributes, which my geb tests can use to synchronize.

Cheers,
11011011

--
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 geb-user+u...@googlegroups.com.
To post to this group, send email to geb-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/geb-user/CA%2B52dQQv7Jeg3D7CGUUw2Usm7%3DunScgGffH-DUW9YyHqF7wPAw%40mail.gmail.com.

[Martin de laat]

Thanks for all your detailed responses. I'm seeing multiple solutions for the 'problem', so I'll try a bunch out. I guess I completely skipped over the waitCondition multiple times.

• (...) Testing for invisibility of asynchronously loaded page elements is always problematic because without waiting the test would pass too quickly and falsely!

I think generally, a user would usually would be able to verify something rightfully isn't being displayed, not because it doesn't show after an arbitrary time interval, but because similar stuff is happening, and that specific thing isn't.

Also, depending on the machine running the tests, how long to wait for is very tricky, so to be safe you specify a timeout period that is significantly longer than required.

Being able to somehow specify those criteria above would improve test speed I think.

Like: as an admin, when I press button A, I should see new buttons B&C. As a user, when I press button A, I should see new button B and not C. In that case, if B shows up and not C, you don't need to wait your full timeout time

[Martin de laat]

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.

It's a separate issue, but I've a hard time with AngularJS assessing when the page is 'settled' and went the other path with implicit waiting. Thanks though, seems like a solid alternative.