search

jjnair / fest

Automatically exported from code.google.com/p/fest
0 stars 0 forks source link

Tests failing in EDT don't provide relevant information #247

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 

Hi,

I've just upgraded to FEST-Swing 1.0b3-SNAPSHOT-2 from 1.0b1.
The very first test that I execute is failing.

Here is the TestNG stack trace:
java.lang.IllegalStateException: Expecting component
javax.swing.JFormattedTextField[name=null, text='0', enabled=true,
visible=true, showing=false] to be showing on the screen
    at
org.fest.swing.driver.ComponentStateValidator.componentNotShowingOnScreenFailure
(ComponentStateValidator.java:87)
    at
org.fest.swing.driver.ComponentStateValidator.validateIsShowing(ComponentStateVa
lidator.java:72)
    at
org.fest.swing.driver.ComponentStateValidator.validateIsEnabledAndShowing(Compon
entStateValidator.java:44)
    at
org.fest.swing.driver.JTextComponentDriver$2.executeInEDT(JTextComponentDriver.j
ava:193)
    at
org.fest.swing.driver.JTextComponentDriver$2.executeInEDT(JTextComponentDriver.j
ava:191)
    at org.fest.swing.edt.GuiQuery.run(GuiQuery.java:42)
    at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
    at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
    at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273
)
    at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
    at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173
)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
    at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)

The problem is that the stack trace doesn't give me enough information
about the failure. It only gives me information about what happened in the EDT.
What I'm really interested in is what happened in the main thread (in my
case, the TestNG thread) so that I can start debugging my test class.

I think that GuiQuery<T> could be constructed with the stack trace of the
current thread.
This would provide information about the main thread up to the moment of
giving the GuiQuery<T> instance to
org.fest.swing.edt.GuiActionRunner.execute(GuiQuery<T>)

I realize that this could be real expensive in terms of performance.
A feasible solution would be to introduce a debug mode, which could be used
like:
frame.robot.settings().debugModeEnabled(true);
With debug mode enabled GuiQuery<T> could be constructed with the stack
trace of the main thread, otherwise without it.

Something similar could be done for the BasicComponentFinder#find(..)
methods, which generate a listing of the AWT component hierarchy if the
component is not found.
It would be possible not to generate the listing with debug mode disabled.
This way the #find(..) methods would be usable again, when only the
presence of a component is interesting (currently #findAll is recommended).

The main idea behind debug mode is that if a test fails and the stack trace
doesn't provide enough information the test could be rerun with debug mode
enabled to help the developer solve the issue quicker.
Debug mode could also be used during the development of tests, where
performance is not an issue. This would be great with large tests.

If constructing the stack trace isn't that expensive, another solution
might be to construct it by default, this way introducing debug mode
wouldn't be necessary at all. Introducing debug mode might bee too
expensive in terms of coding if the codebase had to be reviewed again. I
don't really know what would be the costs.

Another solution might be to have two GuiQuery<T> implementations, one with
stack traces and one without. These could be in a debug jar for development
and a normal jar for deployment, respectively.

I would appreciate some feedback.

Thanks,
Csabi

Original issue reported on code.google.com by csaba.ju...@gmail.com on 4 Dec 2008 at 10:36

GoogleCodeExporter commented 8 years ago 
I agree! Thanks Csabi!

Original comment by Alex.Rui...@gmail.com on 4 Dec 2008 at 4:10

GoogleCodeExporter commented 8 years ago 
Although I think this is very important, I'm going to postponed for version 
1.1. It
may take more time to fix that what I expected.

Original comment by Alex.Rui...@gmail.com on 4 Dec 2008 at 11:37

GoogleCodeExporter commented 8 years ago 
Thought about this issue. We need to fix it by 1.0.

Original comment by Alex.Rui...@gmail.com on 8 Dec 2008 at 9:13

GoogleCodeExporter commented 8 years ago 
It would be even greater if you could fix it in an RC.

Original comment by csaba.ju...@gmail.com on 9 Dec 2008 at 10:07

GoogleCodeExporter commented 8 years ago 
At this point, I don't have plans to release another RC. But definitely this 
bug will
be fixed in 1.0 (mid-January) :)

Thanks!
-Alex

Original comment by Alex.Rui...@gmail.com on 9 Dec 2008 at 10:10

GoogleCodeExporter commented 8 years ago 
Hi Csabi,

I fixed this bug. I think I'd like to keep this behavior always "on" because it 
is
extremely useful when troubleshooting test failures. The changes I made can be 
found at

http://code.google.com/p/fest/source/detail?r=2060 (r2060)

Many thanks for helping us improve FEST!! :)

Best regards,
-Alex

Original comment by Alex.Rui...@gmail.com on 14 Dec 2008 at 7:43

GoogleCodeExporter commented 8 years ago 
Thanks a lot,
Csabi

Original comment by csaba.ju...@gmail.com on 16 Dec 2008 at 3:22