| Re: [swtbot-dev] Who actually runs SWTBot test on hudson.eclipse.org? |
On 08/11/2011 18:04, Ketan Padegaonkar wrote:
That's good to know, I'll probably ask this question on cross-project later.I believe there's EGit and mylyn that use SWTBot for testing, I'm not sure if they actually run the tests on hudson.eclipse.org. What has happened is that the SWTBotStyledTextTest fails with Xvnc and DISPLAY=:1, whereas it is working fine with normal DISPLAY. I totally guessed an explanation, it may be totally wrong (it's pure guess at this point), but I don't get the reason of this difference.To understand your problem better, I'd like to understand what you mean by keyboard and mouse events are shared. Are they shared even though each JVM uses a different $DISPLAY variable? If this is indeed the case, I'd think this could be a bug with either the JVM and/or the window manager. Here is the error output: typesTextAtALocation(org.eclipse.swtbot.swt.finder.widgets.SWTBotStyledTextTest) Time elapsed: 1.315 sec <<< FAILURE! java.lang.AssertionError: Expected: a string containing "---typed Text---" got: "The quick brown fox jumps over the lazy dog.\n---typeOne Two Three" at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:21) at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8) at org.eclipse.swtbot.swt.finder.SWTBotAssert.assertTextContains(SWTBotAssert.java:163) at org.eclipse.swtbot.swt.finder.SWTBotTestCase.assertTextContains(SWTBotTestCase.java:146) at org.eclipse.swtbot.swt.finder.widgets.SWTBotStyledTextTest.typesTextAtALocation(SWTBotStyledTextTest.java:93) The mysterious thing for me is this incomplete "--type" string. But I just found out that it is deterministic behavior. Probably the "d" key is interpreted as something else on my keyboard. I am quite annoyed by the keyboard internationalization issue. I cannot get the test working on my laptop, so that I have to run tests on another slow machine with native language set to English.As far as the different keyboard strategies are concerned. There's historical reasons for those. The major one being that the SWT implementation that relies on Display#post does not work for a few common cases and is sometimes buggy only on certain platforms. AWT implementation has similar quirks on certain JVM and platform combination. I must add that myself and my team have come across less number of these quirks with AWT. In short there's no reliable way to send keyboard events short of reinventing a square wheel. So while not ideal, there's an option for test authors to be able to switch the keyboard strategy at runtime for specific keyboard inputs :-/ Do you think using SWTKeyboardStrategy would help me? If not, do you know a way to get tests working for any keyboard configuration (or at least mine ;) ? Regards, |