Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to assert that element is not visible during specific time? #5

Open
yashaka opened this issue Jan 6, 2021 · 0 comments
Open

How to assert that element is not visible during specific time? #5

yashaka opened this issue Jan 6, 2021 · 0 comments

Comments

@yashaka
Copy link
Contributor

yashaka commented Jan 6, 2021

So, imagine that you submit something, and there might be errors as a result, during some period of time, for example – not more than 5s. More over, if error appear, it will be visible only 1 second, so the code like:

await sleep(5)
await $('#error').should(be.not.visible)

will not work!

So what to do?

currently we can do something like the following to achieve the goal:

assert(await $('#error').with_({timeout=5}).waitUntil(be.visible) == false)

or

assert(await $('#error').with_({timeout=5}).wait.until(be.visible) == false)

or

assert(await $('#error').wait.atMost(5).until(be.visible) == false)

do we need something more kind of user-friendly?

this:

await $('#error').wait.atMost(5).while(be.not.visible)

will be pretty not obvious in understanding...
It's not obvious from the name what is happening here, because the implementation will be not consistent to both

  • wait.until
    • until returns false on "not matched condition" but while will throw exception
      • in programming usually the while is considered an opposite to until in context of "bolean logic", so it would be consistent if while also returned false in case of "not matched"
  • wait.for (throwing exception in case of falsy/not-matched) result)
    • for throws exceptioin as soon as condition not matched, but while throws exception as soon as condition is not matched but just during specific time set
      • the inconsistency here is in "waiting at most, trying to wait less" vs "waiting all the time long"

or am I wrong in the latter? Regardless of being inconsistent in context of technical implementation of for vs while vs until, isn't it consistent with common sense in context of "native English"?

  • Let's wait at most 5 min for hime to appear
    • here we naturally mean that as soon as he comes during period of 5 min - we go togather where we want, otherwise we for example call him and shout with "Exception/Error" ;)
  • Let's wait (and play) during 5 min while mother is not coming (to make us do homework)
    • here we kind of naturally wait for what we want...
      • but yet we change the previous behaviour of waiting... we wait during not at most
        • how to "override" this "at most" logic? I mean how to override it in context of "naming style"?

By the way, from the last example, probably it would be even more natural to say: Let's wait during 5 min unless mother comes (to make us do homework)... Hm... what about this style then:

await $('#error').with_({timeout=5}).wait.unless(be.visible)

note that this is not relevant because atMost interfere by meaning with "during" or "internal/timeout"

await $('#error').wait.atMost(5).unless(be.visible)

yet we are allowed to call atMost on wait, should we remove it then?

but is it really so bad? :) maybe we can live with this .wait.atMost(5).unless(be.visible) ? what a native english speakeer would tell?

or maybe... should we allow both? like make the waiting algorithm to count both "at most timeout" and "during interval"? How this algorithm may look like then?

...

one more question... Won't unless confuse a bit when comparing to until? :)

And... One more idea, what about this:

await $('#error').should(be.not.visible.during({seconds:5}))

?

This is probably something the simplest that we might implement, and it will be useful regardles of the future of while/unless/etc inside wait...

But is it really simple in context of implementing this "general condition" logic. Will it be easy to override wait's timeout with our "during" timeout from condition? Let's see...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant