Community
Participate
Working Groups
The failure has been caused by the fix for bug 162079. http://download.eclipse.org/eclipse/downloads/drops/N20101203-2000/testresults/html/org.eclipse.ui.tests.views.properties.tabbed_macosx.cocoa.x86_5.0.html We do get a post selection event from the ITextViewer but it is done in a Runnable scheduled on a timer exec. Since the test runs "linearly", the timer exec is processed "too late" and the 'Properties' view ends up not getting the selection event in time (for the assertion calls).
Not sure how a bad written test can be considered a major issue. Anyway, fixed this in HEAD and submitted to the next I-build since the UI buildmeister was not available.
(In reply to comment #1) > Not sure how a bad written test can be considered a major issue. I consider failing tests to be major on the grounds that it makes us look bad and/or incompetent. But to each his own of course, the severity field is one that can be set by the reporter after all, and one man's "blocker" is another man's "enhancement request".
> But to each his own of course, the severity field is one > that can be set by the reporter after all, and one man's "blocker" is another > man's "enhancement request". Yes, indeed ;-) I agree that a test failure can be 'Major' (or worse) if it indicates a problem with the production code, but that's not the case here, however, you didn't know that when filing the bug. Anyway, thanks for filing the bug. It saved me the time of filing it.
Verified in I20101205-2000.
Dani, should we make some slight changes to this test after M4 goes out? I feel that the current pattern is dangerous because a potential bug in the selection propagation could cause the array to always be zero which would effectively mean that the tests would hang "forever".
(In reply to comment #5) > Dani, should we make some slight changes to this test after M4 goes out? I feel > that the current pattern is dangerous because a potential bug in the selection > propagation could cause the array to always be zero which would effectively > mean that the tests would hang "forever". That could theoretically happen but note that the tests previously directly fetched the first element in the array without further testing and there was never an issue with that. Having said that, I've improved the tests in HEAD to avoid the potential endless loop.
