Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [swtbot-dev] random test failures and SWTBot timing parameters 
Hi,
Having to change the playback delay typically means slowing down *all* tests by an order of magnitude. This is something that I recommend doing in only exceptional cases. In most cases, you'd set this to a higher value for certain operations, and then set it back to the default.
Changing the tests to use a newer version of swtbot, I do get to see errors on eclipse 3.6 M4, and the stack trace is at the end of the mail. The line numbers may vary, but do you see the same exception that I do (widget not enabled)?
This is happening because the 'Next >' button has not yet been enabled on page 2 of the wizard. See attached screenshot after failure.
I've opened bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=299201 to resolve this. 

Would you prefer it if I fix the test and send a patch across ?

Cheers!

-- Ketan
org.eclipse.swtbot.swt.finder.exceptions.AssertionFailedException: assertion failed: Widget (of type 'Button' and with mnemonic 'Next >' and with style 'SWT.PUSH') is not enabled. at org.eclipse.swtbot.swt.finder.utils.internal.Assert.isTrue(Assert.java:95) at org.eclipse.swtbot.swt.finder.widgets.AbstractSWTBot.assertEnabled(AbstractSWTBot.java:598) at org.eclipse.swtbot.swt.finder.widgets.SWTBotButton.click(SWTBotButton.java:65) at org.eclipse.egit.ui.internal.sharing.GitCloneWizardTest.testCloneDestExists(GitCloneWizardTest.java:145) 
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 
	at java.lang.reflect.Method.invoke(Method.java:592)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) 
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.eclipse.swtbot.swt.finder.junit.SWTBotJunit4ClassRunner.run(SWTBotJunit4ClassRunner.java:54) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.swtbot.eclipse.core.RemotePluginTestRunner.main(RemotePluginTestRunner.java:64) at org.eclipse.swtbot.eclipse.core.UITestApplication.runTests(UITestApplication.java:117) at org.eclipse.ui.internal.testing.WorkbenchTestable$1.run(WorkbenchTestable.java:71) 
	at java.lang.Thread.run(Thread.java:613)



On 1/9/10 6:15 PM, Matthias Sohn wrote:

We are trying to add UI tests to Eclipse EGit using SWTBot.

On my box I face random test failures (using Eclipse 3.5.1). Robin seems
not to face
these problems on 3.4 with an older version of SWTBot.

The only way I found to get rid of these random failures was to increase
the SWTBot timing
parameters to
-Dorg.eclipse.swtbot.playback.poll.delay=500
-Dorg.eclipse.swtbot.playback.delay=400

Is that expected or do I miss some other potential root cause of these
random failures.
Tweaking timing parameters depending on hardware sounds like an
invitation for false negatives
if the same tests run in different environments (OS, hardware, Eclipse,
CI (Hudson, Maven)).

Here the patch and review discussion about what we are trying:
http://egit.eclipse.org/r/#change,137

--
Matthias



_______________________________________________
swtbot-dev mailing list
swtbot-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/swtbot-dev

Attachment: screenshot-GitCloneWizardTest.testCloneDestExists.jpeg
Description: JPEG image

Back to the top