Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 572398

Summary: [Junit] Adding Junit to the classpath but not to imported bundles
Product: [Eclipse Project] PDE Reporter: Christoph Laeubrich <laeubi>
Component: UIAssignee: Christoph Laeubrich <laeubi>
Status: CLOSED WONTFIX QA Contact:
Severity: normal    
Priority: P3 CC: julian.honnen, Vikas.Chandra
Version: 4.18   
Target Milestone: ---   
Hardware: PC   
OS: Linux   
See Also: https://git.eclipse.org/r/c/pde/eclipse.pde.ui/+/178892
https://bugs.eclipse.org/bugs/show_bug.cgi?id=572602
Whiteboard:
Bug Depends on:    
Bug Blocks: 572627    
Attachments:
Description Flags
screenshot of the dialog
none
screenshot of the dialog ater apply the proposed patch none

Description Christoph Laeubrich CLA 2021-03-29 06:30:56 EDT
Created attachment 285975 [details]
screenshot of the dialog

If one adds a testcase it is offered to add the junit to the require-bundles. if one don't write a plugin test but one that do not require OSGi to run it would be more suitable to add it to the classpath instead. This is especially true if one has source and test in the same bundle (e.g. using the new "source folder contains test classes").
Comment 1 Eclipse Genie CLA 2021-04-06 04:52:44 EDT
New Gerrit change created: https://git.eclipse.org/r/c/pde/eclipse.pde.ui/+/178892
Comment 2 Christoph Laeubrich CLA 2021-04-06 05:00:40 EDT
Created attachment 286039 [details]
screenshot of the dialog ater apply the proposed patch

The only problem here is that PDE overrides the default junit fix. Removing the override allows the user to select between the two choices.
Comment 3 Christoph Laeubrich CLA 2021-04-12 13:17:55 EDT
can please anyone from the PDE team review this trivial change? Are there any concerns?
Comment 4 Julian Honnen CLA 2021-04-13 10:37:52 EDT
(In reply to Christoph Laeubrich from comment #3)
> can please anyone from the PDE team review this trivial change? Are there
> any concerns?

Same concerns as in bug 572743, the JDT JUnit library won't work for plugin tests and might confuse users.

The library can always be added manually on the build path page.
Comment 5 Christoph Laeubrich CLA 2021-04-13 11:28:04 EDT
Its also confuses users if options magically disappear... and they need up to 10 clicks what should be available with one click.
Comment 6 Vikas Chandra CLA 2021-04-14 06:26:14 EDT
If user adds Junit4 library to the build path and then tries to run the test case as Junit plugin test, then it wont run. Right?
Comment 7 Christoph Laeubrich CLA 2021-04-14 08:54:38 EDT
(In reply to Vikas Chandra from comment #6)
> If user adds Junit4 library to the build path and then tries to run the test
> case as Junit plugin test, then it wont run. Right?

It will run but no test methods are executed at least for JUnit4, as the annotations are not recognized anymore. I'd tried to propose supporting this as PDE already contains some extra support for JUnit5 but this seems to be not wanted and instead we better force the user adding useless imports to their manifest.

Anyways, the fundamental misunderstanding here is, from my point of view, that if I write a plugin I *only* want to execute Plugin test.

Given I have crafted a nice service implementation, register it via DS or any similar technique my code has no dependency to OSGi and thus running it as a Plugin-Test is simply wasting startup-times as I can completely test my service with a regular JUnit test. Even if it has dependencies to OSGi I can use e.g. Apache Sling OSGi Mocks[1], again no need to fire up a full blown Plugin Test (given that I finally get the config right see Bug 572807 what is just a very simple case for the pain developers face when using Plugin Tests for where plain Unittest would already work without problems).

Next Usecase is, that we want to separate "regular" from "integration" test, the regular ones are next to the code in a "test" marked source folder and should not be runnable as plugin-test anyways. The integration test ones are in a extra projects that are setup for running as plugin tests with proper imports and so on.

So there are valid reasons *not* using Plugin Tests and still develop a plugin/bundle.

(In reply to Julian Honnen from comment #4)
> The library can always be added manually on the build path page.

Additional from hiding the JDT Soloution to the user, PDE makes it extra hard to  even add it manually as in the Plugin perspective it hides the usual "Project > Build Path > Add Library" from the menu.

Instead users need to to:
"No please don't add junit yet", right click on the project "Project > Build Path > Configure Build path", select Libraries, select Classpath, hit "Add Library", select "JUnit", hit next, select the "right" JUnit form the combo, hit finish, hit apply and close.

Interestingly while looking into this I stumbled over an old discussion[2] that states 

>> "We Do Tooling but Our Business is People" - Wassim Melhem

It seems that gotten out of scope over the past years... Instead of trying to solve the underlying problem e.g. by
a) help people to make the right choice between require-bundle or add library -or-
b) just *support* that common case as it is already done for compile-time with juni5) 
c) offer the user a choice when running a plugin test ("it seems required bundles are missing for running this as junit plugin test, do you like to add them now")

the request is simply discarded as invalid (anyone really wondering if people getting mad and looking for alternative IDE solutions instead of contributing to PDE?).


[1] https://sling.apache.org/documentation/development/osgi-mock.html
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=175190#c6
Comment 8 Vikas Chandra CLA 2021-04-14 09:27:53 EDT
The quote is here too https://www.eclipse.org/pde/ (3rd line from the top).

The main concern here is how will user know when to run  "JUnit Plugin Test" and When to run as "JUnit Test". Also default should be "Add org.junit" to the required bundle. Also once that is changed to "Add JUnit4 to build path" there must be way to convey to the user that he or she needs to run that as "JUnit Test" and not "JUnit Plugin Test". Also it will be worth checking with other users too.
Comment 9 Christoph Laeubrich CLA 2021-04-14 09:41:04 EDT
(In reply to Vikas Chandra from comment #8)
> The main concern here is how will user know when to run  "JUnit Plugin Test"
> and When to run as "JUnit Test". 

How do they know today? If I right-click on an arbitrary test and choose Run As I always getter offered two choices:

1) JUnit test (what fails if it actually requires a plugin context)
2) JUnit Plugin Test (what fails if I don't have the 'right' config)

so *how* to run a test as of today seems to be some a-prior knoledge of the user as there is no special annotation or something one can guess from that is really requires a JUnit Plugin Test

> Also default should be "Add org.junit" to the required bundle.

The functionality itself is offered by JDT but as there are option to override an entry it should be valid to have some way to provide an ordering or maybe "recommended" flag in the extension point

> Also once that is changed to "Add JUnit4 to build path"
> there must be way to convey to the user that he or she needs to run that as
> "JUnit Test" and not "JUnit Plugin Test".

From a user point of view it would be optimal if PDE would make some checks before launching. even better would to automatically add an osgi.dev entry that simply puts the required items on the bundle classpath (as its done with junit5 for the compile-classpath) would be satisfactory.

For simplicity even a message:
"No test where run - make sure your bundle imports junit if you like to run it as a plugin test" would already satisfy (most?) of the users, but...

> Also it will be worth checking with other users too.

... maybe I'm also just a special user :-)

Also all of this could be done today (and is done, I know at least from another company doing it similar) its just very inconvenient to do.
Comment 10 Vikas Chandra CLA 2021-04-14 10:03:33 EDT
>>How do they know today? 

That is true ! ApiToolsTestSuite is run as JUnit tests, not JUnit Plug-in Tests . There is a huge comment at the start of this file. ApiToolsPluginTestSuite, on the other hand  is run as JUnit plugin test.

If the default is maintained somehow via "recommended" flag in the extension point or otherwise (hoping users changing default know what they are doing) and we  at least have the message '"No test where run - make sure your bundle imports junit if you like to run it as a plugin test", then this change looks OK to me.
Comment 11 Vikas Chandra CLA 2021-04-20 08:30:06 EDT
Julian, any concerns here if

"If the default is maintained somehow via "recommended" flag in the extension point or otherwise (hoping users changing default know what they are doing) and we  at least have the message '"No test where run - make sure your bundle imports junit if you like to run it as a plugin test", then this change looks OK to me."
Comment 12 Julian Honnen CLA 2021-04-20 08:46:43 EDT
(In reply to Vikas Chandra from comment #11)
> Julian, any concerns here if
> 
> "If the default is maintained somehow via "recommended" flag in the
> extension point or otherwise (hoping users changing default know what they
> are doing) and we  at least have the message '"No test where run - make sure
> your bundle imports junit if you like to run it as a plugin test", then this
> change looks OK to me."

Yes, in my opinion this change is simply wrong for PDE. We should not add any (more) tooling that creates plugins that compile but don't work in a OSGi runtime.
Especially if we add even more configuration complexity for this usecase.

Also we have just removed the "no tests were found" message dialog (that's JDT by the way). I don't want to see it reappear for my workspace (that is when the user did not use this feature).
Comment 13 Christoph Laeubrich CLA 2021-09-16 05:04:02 EDT
It seems there is not much interest in this.