Further clean-ups and simplifications of smartimport-tests

[HannesWell]

Generalize redundant code into the template class.

Replace the o.e.pde.ui.tests.smartimport/pom.xml by the still required pom.model. configuration in the build.properties (many properties were obsolete anyway).

[github-actions]

Test Results

   258 files   -        6     258 suites   - 6   37m 37s ⏱️ - 6m 32s
3 335 tests ±       0  3 304 ✔️ ±       0  30 💤 ±  0  1 ❌ ±0 
4 857 runs   - 2 721  4 813 ✔️  - 2 698  42 💤  - 24  2 ❌ +1 

For more details on these failures, see this check.

Results for commit ec0a0c0. ± Comparison against base commit 912012e.

This pull request removes 4 and adds 4 tests. Note that renamed tests count towards both.

org.eclipse.ui.tests.smartimport.EclipseJavaProjectTest ‑ testImport
org.eclipse.ui.tests.smartimport.FeatureProjectTest ‑ testImport
org.eclipse.ui.tests.smartimport.PlainEclipseProjectTest ‑ testImport
org.eclipse.ui.tests.smartimport.PlainJavaProjectTest ‑ testImport

AllPDETests org.eclipse.ui.tests.smartimport.ProjectSmartImportTest ‑ testImport[FeatureProject]
AllPDETests org.eclipse.ui.tests.smartimport.ProjectSmartImportTest ‑ testImport[JavaEclipseProject]
AllPDETests org.eclipse.ui.tests.smartimport.ProjectSmartImportTest ‑ testImport[PlainEclipseProject]
AllPDETests org.eclipse.ui.tests.smartimport.ProjectSmartImportTest ‑ testImport[PlainJavaProject]

♻️ This comment has been updated with latest results.

[akurtakov]

Now imagine someone to convert it to parameterized test so it becomes single class

[HannesWell]

Now imagine someone to convert it to parameterized test so it becomes single class

Good idea! And since that test-plugin then only contains one class, I think we can just move that test and its resources to the pde.ui.tests Plugin.

[akurtakov]

I strongly believe that incremental improvements are better than trying to do everything it once. E.g. push PR that makes this one single class test and leave the move to pde.ui for another PR . Over the years many such "small" improvements got lost after staling in a bigbang change .

[HannesWell]

I strongly believe that incremental improvements are better than trying to do everything it once. E.g. push PR that makes this one single class test and leave the move to pde.ui for another PR . Over the years many such "small" improvements got lost after staling in a bigbang change .

In general I agree, but in this case I had the changes ready locally and just wanted to submit #745 before to not have to adjust the test-suites twice.

For me this is now ready.

[laeubi]

Now imagine someone to convert it to parameterized test so it becomes single class

parameterized JUnit5 test :-)

I think we can just move that test and its resources to the pde.ui.tests Plugin

If its a plain JUnit test you can even move it inside the plugin that is tested into a separate src_test folder and execute if with plain surefire :-)

[HannesWell]

parameterized JUnit5 test :-)

Migrating to JUnit5 is really something I would lime to do (in the near? future).
But can we do that already? IIRC the I-build Tests had some issues with JUnit5, but I could be wrong.

[akurtakov]

No issue with using JUnit 5 AFAIK. https://github.com/eclipse-platform/eclipse.platform.ui/tree/master/tests/org.eclipse.e4.ui.tests.css.core is one bundle that is exclusively JUnit 5 including @suite usage.

[laeubi]

IIRC the I-build Tests had some issues with JUnit5, but I could be wrong.

Then probably we should open an issue about the issues to track the possible issue :-)