Add a SWTTest Junit extension to allow tests executed in the UI thread

[laeubi]

Currently we require SWT-UI based tests to be executed by special runners known as the 'UIHarness' to be run in the UI thread, what has several problems:

1. is requires usually to fire up a whole workbench (and a workspace) 2) the whole testsuite has to run in the UI thread 3) no way to customize this further
2. actually this is nothing that belongs into the test framework

This now adds a new SWTTest JUnit extension that allows to mark a test class with an extension and get your methods executed in the UI thread.

[github-actions]

Test Results

0 files   -   115  0 suites   - 115   0s ⏱️ - 10m 41s
0 tests  - 4 546  0 ✅  - 4 531  0 💤  - 15  0 ❌ ±0 
0 runs   -   311  0 ✅  -   308  0 💤  -  3  0 ❌ ±0 

Results for commit 1337680. ± Comparison against base commit 84f0345.

♻️ This comment has been updated with latest results.

[laeubi]

This currently is just a proof-of-concept on how we can make testing more self-contained. One likely more wants to use an @UI / @NoUI annotations that can be added to different levels (e.g. methods or classes) and then even switch between the threads in different methods of the same testclass.

Other annotation might be used to drive the event-queue automatically after each test.

so a "typical" SWT test then can look like this:

@UI
@DriveEvents
class MySwtTest {
   

  void testMyWidget() {
    //Will run in the UI and drive the event-queue before/after
  }
  
  @NoUI
  void testRunningOutSide() {
    //Test something outside the UI thread
  }
}

[mickaelistria]

That reminds me of https://bugs.eclipse.org/bugs/show_bug.cgi?id=548970 ;)
I think such an annotation to mark code that is expected to run in UIThread would be great in general; and a JUnit runner/extension that is able to look at this annotation on a Test to decide whether to run it in UI Thread of not would be great!

[laeubi]

That reminds me of https://bugs.eclipse.org/bugs/show_bug.cgi?id=548970

Any coincidence is only random :-P

I think such an annotation to mark code that is expected to run in UIThread would be great in general; and a JUnit runner/extension that is able to look at this annotation on a Test to decide whether to run it in UI Thread of not would be great!

I really like to go in that direction because it shifts responsibility from Tycho (where it does not belong to), to the actual "library" (SWT/Platform) what is a much better fit.

I'm just noch sure where to best place such code:

1. Should be some at SWT and some at platform?
2. Should it be a separate module or not?

We already have org.eclipse.test bundle that has dependencies on junit + platform and some code in Tycho seems to be "inspired" by this. And it seems quite a lot of test bundles actually reference this I'm just not 100% sure about its general purpose and it seems not deployed to maven yet ( @merks ? ).

Of course one might also start with something "fresh" but where should it be located? Tycho? Platform? and own project?

[merks]

I didn't think that org.eclipse.test was meant to be "API" used outside of the Platform's own builds.

[iloveeclipse]

Why is this added on SWT production code, not in SWT tests?
Eclipse usually does not mix production & test code in one bundle / source directory.

[iloveeclipse]

Should it be Display.getCurrent() != null ?

[laeubi]

Why is this added on SWT production code, not in SWT tests?

Because it is not test code but something you will need to use in production see:

I'm just noch sure where to best place such code ... #2624 (comment)

[mickaelistria]

While those are generic about SWT, I suggest we add such code to org.eclipse.ui.tests.harness, which is often used as a test depedency and provides the widely used DisplayHelper which is IMO comparable in term of goal (providing API-ish to facilitate writing tests for SWT-based apps).

[laeubi]

The place do not matter much to me unless it:

1. is deployed on maven central
2. can be used outside platform without pulling all platform in