Community
Participate
Working Groups
Recently we did a lot of enhancements in Quick Access. I suggest we also rework the old test suites so that it works again and enable it.
Patrik, can you take this one?
Yes, I will work on this. it seems important to me.
New Gerrit change created: https://git.eclipse.org/r/86144
@Patrik: do you think you can get it working for RC2? It's the last opportunity to add tests.
I will take a stab at it this evening. If the build starts at Wed 20:00 EDT, I think I have few hours to try to fix this (the deadline is at 02.00 CEST).
(In reply to Mickael Istria from comment #4) > @Patrik: do you think you can get it working for RC2? It's the last > opportunity to add tests. Mickael, correct me if I'm wrong: to verify the test suite before submitting the change, I should select the QuickAccessTestSuite, right-click it, then select run as > JUnit Plug-in Tests. If I'm wrong, please point me to a document explaining the standard procedure to verify the tests.
With the proposed change, the QuickAccessTestSuite is enabled, and the three failing tests are disabled.
Reopening as no change was merged.
We should investigate why some tests are failing and then either fix the code or the tests. Too late for 4.7.
The tests were failing for: 1. The setup didn't wait for openTestWindow(); 2. The behavior of QuickAccess is changed, as it does not display status messages on the table anymore. With the proposed change the tests are restored and updated to the current behavior of QuickAccess. Note: I plan to add more QuickAccess tests in the future.
Gerrit change https://git.eclipse.org/r/86144 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=8308a2d8daed268e9a2ac3792b2bd5180cfa7dfb
Merged on master, thanks Patrik. Let's wait for a new official build tomorrow or so to make sure it didn't break anything before we backport it to 4.7.1.
(In reply to Eclipse Genie from comment #11) > Gerrit change https://git.eclipse.org/r/86144 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > ?id=8308a2d8daed268e9a2ac3792b2bd5180cfa7dfb Note that version bump is tracked in another patch: https://git.eclipse.org/r/#/c/100794/
(In reply to Mickael Istria from comment #12) > Merged on master, thanks Patrik. > Let's wait for a new official build tomorrow or so to make sure it didn't > break anything before we backport it to 4.7.1. We have now one extra UI test failure in every build: http://download.eclipse.org/eclipse/downloads/drops4/I20170709-2000/testresults/html/org.eclipse.ui.tests_ep48I-unit-win32_win32.win32.x86_8.0.html No runnable methods java.lang.Exception: No runnable methods at java.lang.reflect.Constructor.newInstance(Constructor.java:422) at java.lang.reflect.Constructor.newInstance(Constructor.java:422) at org.eclipse.test.EclipseTestRunner.getTest(EclipseTestRunner.java:640) at org.eclipse.test.EclipseTestRunner.<init>(EclipseTestRunner.java:594) at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:348) at org.eclipse.test.UITestApplication.lambda$0(UITestApplication.java:195) at org.eclipse.test.UITestApplication$$Lambda$297/21324909.run(Unknown Source) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:37) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:182) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4213) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3820) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1150) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1039) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:153) at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:680) at org.eclipse.ui.internal.Workbench$$Lambda$14/29774113.run(Unknown Source) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:594) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:151) at org.eclipse.test.UITestApplication.runApplication(UITestApplication.java:139) at org.eclipse.test.UITestApplication.run(UITestApplication.java:61) at org.eclipse.test.UITestApplication.start(UITestApplication.java:210) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:653) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:590) at org.eclipse.equinox.launcher.Main.run(Main.java:1499) at org.eclipse.equinox.launcher.Main.main(Main.java:1472) at org.eclipse.core.launcher.Main.main(Main.java:34)
(In reply to Andrey Loskutov from comment #14) > (In reply to Mickael Istria from comment #12) > > Merged on master, thanks Patrik. > > Let's wait for a new official build tomorrow or so to make sure it didn't > > break anything before we backport it to 4.7.1. > > We have now one extra UI test failure in every build: > http://download.eclipse.org/eclipse/downloads/drops4/I20170709-2000/ > testresults/html/org.eclipse.ui.tests_ep48I-unit-win32_win32.win32.x86_8.0. > html > > No runnable methods > > java.lang.Exception: No runnable methods > at java.lang.reflect.Constructor.newInstance(Constructor.java:422) > at java.lang.reflect.Constructor.newInstance(Constructor.java:422) > at org.eclipse.test.EclipseTestRunner.getTest(EclipseTestRunner.java:640) > at org.eclipse.test.EclipseTestRunner.<init>(EclipseTestRunner.java:594) Thanks for reporting that. This seems to work fine with tycho-surefire plugin. I'll investigate what makes the difference there.
I believe the error is caused by the JUnit runner used by Platform Build requires an @RunWith(AllTests.class) annotation on the test suite. Or even better, we can convert the TestSuite to JUnit4 and use @RunWith(Suite.class) and @SuiteClasses(...) annotations. @Patrik: can you please take care of it?
For details about the failure see bug 474777.
The tests are failing on all platforms for days now. Please either fix or revert.
New Gerrit change created: https://git.eclipse.org/r/101422
(In reply to Eclipse Genie from comment #19) > New Gerrit change created: https://git.eclipse.org/r/101422 Because no one from original reviewers answered, I've created reverted patch.
(In reply to Eclipse Genie from comment #19) > New Gerrit change created: https://git.eclipse.org/r/101422 A commit was pushed yesterday to hopefully fix it: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=6ead06bcbaecbba7525b6834b34c172b6684b8a2 Unfortunately, yesterday's infra issue made that this commit wasn't linked from bugzilla so no notification was sent. The ongoing build should show whether the patch fixes the issue or not. But there is no need to revert then.
The test are now running. However, one of them already reported a failure: http://download.eclipse.org/eclipse/downloads/drops4/I20170718-0355/testresults/html/org.eclipse.ui.tests_ep48I-unit-mac64_macosx.cocoa.x86_64_8.0.html
Added https://git.eclipse.org/r/#/c/101319/ to See Also (In reply to Mickael Istria from comment #22) > The test are now running. However, one of them already reported a failure: > http://download.eclipse.org/eclipse/downloads/drops4/I20170718-0355/ > testresults/html/org.eclipse.ui.tests_ep48I-unit-mac64_macosx.cocoa.x86_64_8. > 0.html I can fix the error.
Below you can see QuickAccessDialogTest, where the test fails on MacOs text.setText("T"); //.. int oldCount = table.getItemCount(); assertTrue("Not enough quick access items for simple filter", oldCount > 3); assertTrue("Too many quick access items for size of table", oldCount < 30); //<-- Fails The test was added by Curtis in 2013. Back then, probably the max size of quick access results was constrained to 30. (Please let me know if you know this for sure) The actual number of items in the quick access table is variable and depends on the size of the popup. To ensure repeatability, I intend to fix this error by removing the assert on count < 30.
To be more clear, (In reply to Patrik Suzzi from comment #24) > The actual number of items in the quick access table is variable and depends > on the size of the popup. So, it happens that the test passes on Windows and fails on Mac. > To ensure repeatability, I intend to fix this error by removing the assert > on count < 30.
The maximum number of elements is 60, as defined in QuickAccessDialog and in SearchField. I will update the tests accordingly.
New Gerrit change created: https://git.eclipse.org/r/101465
Gerrit change https://git.eclipse.org/r/101465 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=9db4199d3722a760e0494dc897458bfe980f87cf
@Mickael: thanks for adding JUnit4 annotations. Closed as Resolved Fixed.
Given the amount of commits that were involved, let's avoid the backport then.
(In reply to Patrik Suzzi from comment #26) > The maximum number of elements is 60, as defined in QuickAccessDialog and in > SearchField. I will update the tests accordingly. Why is the behavior/result different on Mac?
(In reply to Eclipse Genie from comment #28) > Gerrit change https://git.eclipse.org/r/101465 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=9db4199d3722a760e0494dc897458bfe980f87cf > Reopening, as it is not clear whether this was the right fix, or whether we have a real problem.
(In reply to Dani Megert from comment #31) > Why is the behavior/result different on Mac? I did the first test on windows, via "Run as JUnit Plugin Test" and it produced no errors, so I thought the behavior was different on Win wrt Mac (see Comment 22). Then, I tested with "mvn clean verify -Pbuild-individual-bundles", which produced same output error reported in Comment 22. So I realized the JUnit plugin test behaves differently w.r.t the maven one. So, comment 25, was actually about the difference between "JUnit Plugin test" and Gerrit build test. Before committing (comment 27) I verified on my Window computer that the mvn test produces equal results as in the build. I believe this bug can be closed safely.
Resolving as per last comment.
