Eventually() should have a variable time delay

Bug #1083435 reported by Jeff Lane 
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Autopilot
Fix Released
Wishlist
Unassigned
autopilot (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Looking at the code for Autopilot it seems that Eventually is hard coded to wait for 10 seconds. In playing with this with Checkbox, I found that sometimes that 10 second delay is not enough.

For example, it takes 15 - 20 seconds for buttonStartTesting to become enabled once tabTestList is visible because of some background stuff going on with checkbox at this point of the run. because of this, I have to introduce a sleep() call to force some extra time.

It would be nice if Eventually() accepted a wait time in seconds. Even better if this was passed through other things that call it. For example: assertProperty(objectProxy, property=value) also calls eventually. So if I do this:

sleep(20)
assertProperty(objectProxy, property=value)

it will sleep for 20 seconds, then assertProperty calls Eventually() internally which adds another 10 second delay.

Related branches

Jeff Lane  (bladernr)
tags: added: certification
Revision history for this message
Thomi Richards (thomir-deactivatedaccount) 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.

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.

Cheers,

Changed in autopilot:
assignee: nobody → Thomi Richards (thomir)
status: New → Incomplete
importance: Undecided → Wishlist
Revision history for this message
Jeff Lane  (bladernr) wrote : Re: [Bug 1083435] Re: Eventuallyr() should have a variable time delay

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

summary: - Eventuallyr() should have a variable time delay
+ Eventually() should have a variable time delay
Changed in autopilot:
status: Incomplete → In Progress
Changed in autopilot:
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package autopilot - 1.2daily12.12.10-0ubuntu1

---------------
autopilot (1.2daily12.12.10-0ubuntu1) raring; urgency=low

  [ Didier Roche ]
  * debian/control:
    - update build-dep for latest deps
  * Automatic snapshot from revision 90 (bootstrap):
    - autopilot is checking for gtk2 gconf instead of real (LP: #1060973)
    - autopilot exits with 0 when a test error-ed (LP: #1050208)
    - Fixes a wrong import of make_proxy_object_from_service_name.
      (LP: #1053023)
    - autopilot crashed with AssertionError in _get_name_from_path(): Path must
      be within the project (LP: #1044701)
    - Adds a man page for autopilot (LP: #1037940)

  [ Thomi Richards ]
  * Autopilot ibus module should use Gir ibus module, not 'python-ibus'
    (LP: #1078917)
  * No timestamp in verbose log (LP: #1067161)
  * Less than (<) keypress emulates as a greater than keypress (>) (LP:
    #1081318)
  * Eventually() should have a variable time delay (LP: #1083435)

  [ Leo Arias ]
  * Typos in getting started page (LP: #1078692)
  * Typo in writing good tests page (LP: #1079129)
  * Typo in docs: responde (LP: #1078680)
  * Typo in docs: autopiolot (LP: #1078683)
  * Typo in running autopilot page (LP: #1078710)

  [ Francis Ginther ]
  * UnicodeDecodeError after test-suite has finished (LP: #1078732)

  [ Martin Mrazik ]
  * UnicodeDecodeError after test-suite has finished (LP: #1078732)

  [ Automatic PS uploader ]
  * Automatic snapshot from revision 111
 -- Automatic PS uploader <email address hidden> Mon, 10 Dec 2012 00:01:06 +0000

Changed in autopilot (Ubuntu):
status: New → Fix Released
Changed in autopilot:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.