Add method $.shouldBe(condition, timeout)

[asolntsev]

The problem

Selenide has method for waiting for a condition with custom timeout:

• $.waitUntil(visible, 8888);
• $.waitWhile(visible, 9999);

But it's not always readable. See $.waitUntil(attribute("href", "blah"), 8888);.

Solution

It would be better readable if method name was should/shouldBe/shouldHave instead of waitUntil (but with timeout parameter):

• $.shouldBe(visible, 8888);
• $.shouldHave(attribute("href", "blah"), 9999);

P.S. Selenide already uses this pattern for collections:

• $$("tr").shouldHave(size(42));
• $$("tr").shouldHave(size(42), 9999);

Tell us about your environment

• Selenide Version: 5.11.1

[dstekanov]

I think we should have these methods. Also, shoulds accept Condition... but waitUntil does not

[asolntsev]

@dstekanov There is a nuance :)
In Java, you cannot add long parameter after vararg: $.shouldBe(visible, enabled, 9999);

That's why I suggest to have "waiting" methods with only one condition. As a rule, you want to use big timeout to wait for a single condition.

[SeleniumTestAB]

Hmm why not sometihng like that element.shouldBe(visible, enabled).after(timeout); ?
OR
element.after(timeout).shouldBe(Condition...)

[asolntsev]

@SeleniumTestAB Good idea, but...

1. element.shouldBe(visible, enabled).after(timeout) - cannot work, because the first part element.shouldBe(visible, enabled) already does its job.
2. But these options are possible:

• element.after(timeout).shouldBe(Condition...)
• element.shouldBe(Condition...)
• element.shouldBe(visible.in(5, SECONDS), enabled.in(8, SECONDS)

[SeleniumTestAB]

hmm, why not not do element.shoulBe(visible.in(Duration duration)) ? Like i am not sure if you really need to specify the time measure... unless its complex to handle it that way,

[asolntsev]

I agree, the unit is almost always SECONDS, but without the unit it's not clear what `in(5) means:

element.shoulBe(visible.in(5))

[SeleniumTestAB]

yes thus i mentioned Duration class from java so that we can use :
element.shouldBe(visible.in(Duration.ofMiniutes(5));

Thats much readable but problem is to how Selenide can check if its in Minutes or Seconds... hmm i think for starter we could set it for Seconds and maybe later see feedback from community?
@asolntsev

[SeleniumTestAB]

@asolntsev there is one issue thought with Condition.in(timeout) method. The conditions such as exist or visible are a static variables and adding in() to them wouldnt make it change timeout for not one occurance but all occurances in the code?

[asolntsev]

No, it's not a problem.
Look how method Condition.because is implemented: it always returns a new Condition instance.

[SeleniumTestAB]

So the finall thing should be:
element.shouldBe(visible.after(Duration timeout));
in my opinion if we stick to duration, however if we want to explicity say the type of time measure then we can use the aforementioned form and:
element.shoulHave(attribute("someAttribute", "someValue").in(4, SECONDS));

[raidora]

I hope there isn't a rule against necroing a thread.

My 2 cents go in favour of using Duration objects as well. int, temporalunit parameters almost feel like a hack next to it.
And you save the hassle of internally having to keep track of the provided temporalunit.

The users still retain the ability to input the integer in whatever unit they wish through Java's Duration class.
Duration.ofMinutes(2); Duration.ofSeconds(10); Duration.ofMillis(1450) etc.

Using Duration for timeouts in Selenide might promote proper time unit usage throughout the users' test code as well.
Maybe one day we won't find timeouts like 5000 or 5*1000 in test projects using Selenide.

[asolntsev]

@raidora Sure, any help is appreciated.
Yes, I agree that using TemporalUnits seems to be a good choice.

[asolntsev]

@raidora Please take a look at #1340

I added methods $.shouldBe(Condition, Duration) and $.shouldHave(Condition, Duration) as a replacement for $.waitUntil and $.waitWhile.

The only thing that I am in doubt about: we don't have alternative for method waitUntil(Condition condition, long timeoutMilliseconds, long pollingIntervalMilliseconds). But probably people never use this third parameter pollingIntervalMilliseconds (I hope so)?

[asolntsev]

implemented in #1340