Comment 2 for bug 1083435

On 12/02/2012 05:30 PM, Thomi Richards wrote:
> Hi Jeff,
>
> This sounds like a do-able feature addition. Thinking about it from an
> API point of view, would you be happy with this?
>
> self.assertThat(foo.something, Eventually(Equals(24), timeout=20)
>
> ... to make Eventually wait 20 seconds. Leaving the keywork property
> out:
>
> self.assertThat(foo.something, Eventually(Equals(24))
>
> would default to 10 seconds.

That would be great, actually. Eventually seems to be pretty useful, I
just happend to run into a case where Eventually() was timing out before
the event I was waiting on could finish.

> AssertProperty is harder to fix - since there's no easy way to
> differentiate between a 'timeout' keyword, and a test against an
> attribute called 'timeout'.
>
> Another option is to have some call like:
>
> self.setAssertionTimeout(20)
>
> which would set the timeout value to 20 seconds for the current test
> only. It's less fine-grained, but would work for both assertions.
>
> I'm keen to get your feedback on this.

How about simply having AssertProperty call Eventually() with a default
timeout of 1 (or is 0 possible with a timeout)?

Doesn't AssertProperty() simply call Eventually() the same way you would
via AssertThat()?

In any case, TBH, the AssertProperty() thing is only a cosmetic issue,
not one of functionality. It just seemed to me that waiting for a
timeout on something that is supposed to simply check NOW that
property=value was overkill. BUT, it doesn't affect the outcome in any
case, so if it's not an easy fix, I don't think it's as important an
improvement as making Eventually() accept variable timeouts.

--
Jeff Lane - Hardware Certification Engineer and Test Tools Developer
Ubuntu Ham: W4KDH
Freenode IRC: bladernr or bladernr_
gpg: 1024D/3A14B2DD 8C88 B076 0DD7 B404 1417 C466 4ABD 3635 3A14 B2DD