Improve error messages in CompletionTest #906

[HeikoKlare]

Provide more meaningful error message in case any of the test cases in CompletionTest fails. Particularly also explicitly validate whether the proposal list widget has been disposed concurrently. Remove typo in method name.

Contributes to #906

[github-actions]

Test Results

     852 files  ±0       852 suites  ±0   1h 10m 10s ⏱️ - 3m 21s
  7 207 tests ±0    7 056 ✔️ ±0  149 💤 ±0  2 ❌ ±0 
22 767 runs  ±0  22 278 ✔️ ±0  487 💤 ±0  2 ❌ ±0 

For more details on these failures, see this check.

Results for commit d968a8c. ± Comparison against base commit 3792903.

♻️ This comment has been updated with latest results.

[fedejeanne]

Looks good to me.
If I interpret your changes correctly then the "old" failure message (org.eclipse.swt.SWTException: Widget is disposed) would be replaced by an assertion error in line 136, right? Is there any way to see why has the widget been disposed or who disposed of it?

[HeikoKlare]

In case the widget is disposed right before the check (i.e. between the last access to the widget and that check), then yes, the test will now fail with an assertion error.
You may register a DisposeListener to a widget, but I do not think that it will provide the information why or by whom the widget has been disposed. My guess is that the widget is disposed because of losing focus for whatever reason, as a completion proposal window is (from my understanding) only shown as long as it has focus.

I would like to avoid the artificial waiting time for the proposals being computed and thus the time the proposal window has to be shown in the test as proposed in #967.

[fedejeanne]

My guess is that the widget is disposed because of losing focus for whatever reason, as a completion proposal window is (from my understanding) only shown as long as it has focus.

I agree, I even reproduced this error in Windows by stopping the execution with a breakpoint right before calling checkCompletionContent. Since I needed to resume the execution of the test in my IDE, I stole the focus from the Shell/Table and the test failed.

I thought maybe one could prevent the focus from being stolen while running tests but I found this in the javadoc of the class Shell and got discouraged.

Note: The styles supported by this class are treated as HINTs, since the window manager for the desktop on which the instance is visible has ultimate control over the appearance and behavior of decorations and modality. For example, some window managers only support resizable windows and will always assume the RESIZE style, even if it is not set. In addition, if a modality style is not supported, it is "upgraded" to a more restrictive modality style that is supported. For example, if PRIMARY_MODAL is not supported, it would be upgraded to APPLICATION_MODAL. A modality style may also be "downgraded" to a less restrictive style. For example, most operating systems no longer support SYSTEM_MODAL because it can freeze up the desktop, so this is typically downgraded to APPLICATION_MODAL

Tricky issue :-\

[HeikoKlare]

Test failures are already documented: #926 and #294