Community
Participate
Working Groups
Created attachment 150674 [details] Stack trace for MWindowTest#testCreateView() Something changed on October 26th and now there are 30+ tests failing in the UIAllTests. The first test that fails is testCreateView(), stack trace attached.
I'm starting to look at this now, it's likely related to the move to the event broker...
Committed in >20091028. I had removed code that forced widget creation in stacks, leading to the majority of the failures. We're now down to 1 Error (in MSashTest) and 4 failures: testCreateMenu testCanExecute test_SwitchActivePartsInCode (for both the Contacts & e4Photo). I'll be looking at these tomorrow...
Committed in >20091029. I've added extra code to the 'createWorkbenchContext' that will create an EventBroker instance *if* there isn't already one in the Application context. This is a hack to allow the MSashTest to gain access to the broker when running 'headless'... Once we clean up the context creation we should make sure we're back to a single broker and that it's at the correct level.
There seems to be some cascading effect that's causing the test_SwitchActivePartsInCode tests to fail. If I move the StartupTestSuite suite to the top it's okay. If it's second place then they fail.
We're still at 3 test failures heading into M2 PW
I've moved StartupTestSuite to the top for now. We'll see whether this "helps" on this test machine or not.
(In reply to comment #6) > I've moved StartupTestSuite to the top for now. We'll see whether this "helps" > on this test machine or not. Well, it went down to 1. :o http://download.eclipse.org/e4/downloads/drops/I20091115-2100/results/html/org.eclipse.e4.ui.tests_linux.gtk.ppc.html
Committed in >20091117. Refactored the PRE to have @PostConstruct and @PreDestroy bookends to ensure that the two subscriptions it makes are unsubscribed. Note that I've opened Bug 295391 to see whether we can handle this on the user's behalf (since I think most naive clients *will* forget).
I guess it didn't make the 2100 build? http://download.eclipse.org/e4/downloads/drops/I20091117-2100/results/html/org.eclipse.e4.ui.tests_linux.gtk.ppc.html
Before I forget (since I already forgot once and had to debug again), the NPEs in the setInput method is because the client object has been uninjected (and 'uiItem' has been reset to null). The reason this is _not_ observed when you actually run the photo demo and close it is because PRE's stop() method will simply dispose and unbind the widgets without disposing the context. I could easily just add a null check but it's not clear to me if this is the pattern I should be using. Seems strange from a client point of view but maybe that's just me?
We're down to 2 test failures: org.eclipse.e4.ui.tests.application.UIContactsDemoTest.test_SwitchActivePartsInCode and org.eclipse.e4.ui.tests.application.UIContactsDemoTest.test_SwitchActivePartsInCode2 PW
(In reply to comment #11) > We're down to 2 test failures: > org.eclipse.e4.ui.tests.application.UIContactsDemoTest.test_SwitchActivePartsInCode > and > org.eclipse.e4.ui.tests.application.UIContactsDemoTest.test_SwitchActivePartsInCode2 I have wiped those from the tests (literally deleted). The code tests that switching the active child alters the active part chain in the context. Changing the active child should _not_ switch the active part, it is more like a "bring to top" request. A variant of these may be revived at a later stage.
92/0/0 http://download.eclipse.org/e4/downloads/drops/I20091119-0815/results/html/org.eclipse.e4.ui.tests_linux.gtk.ppc.html
