[#FEST-32] ContainerFixture#dialog(long timeout) and similar methods (issue 168) - jira.codehaus.org

FEST

ContainerFixture#dialog(long timeout) and similar methods (issue 168)

Created: 03/Mar/09 07:45 PM Updated: 20/May/09 09:05 PM Resolved: 20/May/09 09:05 PM

Return to search

Component/s:

Swing

Affects Version/s:

FEST-Swing 1.1

Fix Version/s:

FEST-Swing 1.2a2

Time Tracking:

Not Specified

Description

« Hide

I am using version 1.0a3 of the FEST-Swing module.

I currently use Thread.sleep to synchronize with dialogs. I have a problem guessing how long each operation is going to take. WindowFinder is a step closer to a solution, but using it is problematic. Using it brakes the fluency of the API. It should be used only in drivers.

One solution would be to add synchronization in the fixtures themselves. For example, you could add

ContainerFixture#dialog(long timeout)

which could use WindowFinder to find the dialog.

In general, all methods returning fixtures for windows or dialogs and all methods returning fixtures for components which create windows or dialogs (like ContainerFixture's file chooser) should have a variant accepting a timeout.

Adding synchronization to fixtures seems reasonable as it is normal for the user to wait for something to pop up while following a trajectory in the GUI.

Thanks,
Csabi

Original report: Issue 168 (Google Code)

Sort Order:

Alex Ruiz made changes - 04/Mar/09 08:43 AM

Field	Original Value	New Value
Component/s		Swing [ 13781 ]

Alex Ruiz made changes - 10/Mar/09 02:16 AM

Description

I am using version 1.0a3 of the FEST-Swing module.

I currently use {{Thread.sleep}} to synchronize with dialogs. I have a problem guessing how long each operation is going to take. {{WindowFinder}} is a step closer to a solution, but using it is problematic. Using it brakes the fluency of the API. It should be used only in drivers.

One solution would be to add synchronization in the fixtures themselves. For example, you could add

{code:java}
ContainerFixture#dialog(long timeout)
{code}

which could use {{WindowFinder}} to find the dialog.

In general, all methods returning fixtures for windows or dialogs and all methods returning fixtures for components which create windows or dialogs (like {{ContainerFixture}}'s file chooser) should have a variant accepting a timeout.

Adding synchronization to fixtures seems reasonable as it is normal for the user to wait for something to pop up while following a trajectory in the GUI.

Thanks,
Csabi

----

Original reports at [Issue 168 (Google Code)|http://code.google.com/p/fest/issues/detail?id=168] & [~~FEST-31~~ (Project Kenai)|http://kenai.com/jira/browse/FEST-31].

I am using version 1.0a3 of the FEST-Swing module.

I currently use {{Thread.sleep}} to synchronize with dialogs. I have a problem guessing how long each operation is going to take. {{WindowFinder}} is a step closer to a solution, but using it is problematic. Using it brakes the fluency of the API. It should be used only in drivers.

One solution would be to add synchronization in the fixtures themselves. For example, you could add

{code:java}
ContainerFixture#dialog(long timeout)
{code}

which could use {{WindowFinder}} to find the dialog.

In general, all methods returning fixtures for windows or dialogs and all methods returning fixtures for components which create windows or dialogs (like {{ContainerFixture}}'s file chooser) should have a variant accepting a timeout.

Adding synchronization to fixtures seems reasonable as it is normal for the user to wait for something to pop up while following a trajectory in the GUI.

Thanks,
Csabi

----

Original report: [Issue 168 (Google Code)|http://code.google.com/p/fest/issues/detail?id=168]

Alex Ruiz made changes - 12/Mar/09 06:09 PM

Assignee

Alex Ruiz [ alexruiz ]

Alex Ruiz made changes - 28/Apr/09 02:43 AM

Fix Version/s	Cairo [ 15055 ]
Fix Version/s		Kiev [ 15264 ]

Alex Ruiz made changes - 20/May/09 09:05 PM

Remaining Estimate		0 minutes [ 0 ]
Original Estimate		0 minutes [ 0 ]

Alex Ruiz made changes - 20/May/09 09:05 PM

Resolution		Fixed [ 1 ]
Status	Open [ 1 ]	Resolved [ 5 ]