fix(execution): detect JUnit test kind from project classpath #93

Merged

fred merged 1 commit from fix/85-junit-kind-detection into main

2026-09-07 19:07:40 +00:00

hauschel.fred commented

2026-09-07 18:58:47 +00:00

Collaborator

Fixes #85: ExecutionTools.java hatte org.eclipse.jdt.junit.TEST_KIND an
zwei Stellen hart auf junit5 gesetzt. Das Produkt bündelt aber Loader für
JUnit 4, 5 und 6 (org.eclipse.jdt.junit4/5/6.runtime). Neue Helper-Methode
detectTestKind(IJavaProject) liest die JUnit-Modul-Jars vom aufgelösten
Klassenpfad (Muster: bestehende Classpath-Auswertung in ExecutionTools
~Z.427-437) und wählt den passenden Loader:

junit-4.x.jar → junit4
junit-jupiter-*/junit-platform-* Major 5/1 → junit5
junit-jupiter-*/junit-platform-* Major 6 (JUnit 6 vereinheitlicht
die Versionierung) → junit6
Kein JUnit gefunden → selbstheilende Fehlermeldung (welche Dependency
fehlt, welcher Reimport nötig ist), keine NPE/leerer Fehler.

Refs #71: Verifikation, ob das gebündelte junit5.runtime (1.2.0) mit
JUnit Platform 1.11 (fixture-core, JUnit 5.11.4) läuft, sobald der Loader
korrekt gewählt wird.

Befund: nein. Auch mit korrekt erkanntem junit5-Loader stürzt die
Test-JVM mit NoClassDefFoundError: org/junit/platform/engine/ OutputDirectoryCreator ab — der Eclipse-JDT-Loader erwartet eine neuere
JUnit-Platform-API als 1.x liefert. Das ist eine echte Inkompatibilität,
kein Erkennungsfehler. Kein eigener Runner (Koordinator-Entscheidung);
stattdessen:

Die Timeout-Meldung von jdt_run_tests/jdt_start_tests_async nennt
jetzt den JUnit-Platform-Mismatch explizit statt der irreführenden
"Spring context"-Vermutung.
README "Bekannte Einschränkungen" aktualisiert: JUnit 6 funktioniert
(siehe unten), JUnit Platform 1.x (JUnit 5) nicht — Empfehlung: auf
JUnit 6 heben oder jdt_maven_build(goals="test") als Workaround.

Verifikation

mvn -pl org.naturzukunft.jdt.mcp -am compile grün
mvn clean package grün, tests/smoke-test.sh 9/9 grün
Gegen den gebauten Server (stdio) importiert und jdt_run_tests
aufgerufen:
- arknet-shared-kernel (JUnit 6.1.3): junit6 korrekt erkannt,
  LocalizedLiteralTest 6/6 grün.
- fixture-core (JUnit 5.11.4 / Platform 1.11, Temp-Kopie): junit5
  korrekt erkannt, Testlauf schlägt wie oben beschrieben mit klarer
  Fehlermeldung fehl (Befund für #71, kein Bugfix).
Fixtures bleiben auf JUnit 5, nicht hochgezogen.

🤖 Generated with Claude Code

https://claude.ai/code/session_016tHV1dzUTdTwMLgx6yotVd

Fixes #85: `ExecutionTools.java` hatte `org.eclipse.jdt.junit.TEST_KIND` an zwei Stellen hart auf `junit5` gesetzt. Das Produkt bündelt aber Loader für JUnit 4, 5 und 6 (`org.eclipse.jdt.junit4/5/6.runtime`). Neue Helper-Methode `detectTestKind(IJavaProject)` liest die JUnit-Modul-Jars vom aufgelösten Klassenpfad (Muster: bestehende Classpath-Auswertung in `ExecutionTools` ~Z.427-437) und wählt den passenden Loader: - `junit-4.x.jar` → junit4 - `junit-jupiter-*`/`junit-platform-*` Major `5`/`1` → junit5 - `junit-jupiter-*`/`junit-platform-*` Major `6` (JUnit 6 vereinheitlicht die Versionierung) → junit6 - Kein JUnit gefunden → selbstheilende Fehlermeldung (welche Dependency fehlt, welcher Reimport nötig ist), keine NPE/leerer Fehler. Refs #71: Verifikation, ob das gebündelte `junit5.runtime` (1.2.0) mit JUnit Platform 1.11 (fixture-core, JUnit 5.11.4) läuft, sobald der Loader korrekt gewählt wird. **Befund: nein.** Auch mit korrekt erkanntem junit5-Loader stürzt die Test-JVM mit `NoClassDefFoundError: org/junit/platform/engine/ OutputDirectoryCreator` ab — der Eclipse-JDT-Loader erwartet eine neuere JUnit-Platform-API als 1.x liefert. Das ist eine echte Inkompatibilität, kein Erkennungsfehler. Kein eigener Runner (Koordinator-Entscheidung); stattdessen: - Die Timeout-Meldung von `jdt_run_tests`/`jdt_start_tests_async` nennt jetzt den JUnit-Platform-Mismatch explizit statt der irreführenden "Spring context"-Vermutung. - README "Bekannte Einschränkungen" aktualisiert: JUnit 6 funktioniert (siehe unten), JUnit Platform 1.x (JUnit 5) nicht — Empfehlung: auf JUnit 6 heben oder `jdt_maven_build(goals="test")` als Workaround. ## Verifikation - `mvn -pl org.naturzukunft.jdt.mcp -am compile` grün - `mvn clean package` grün, `tests/smoke-test.sh` 9/9 grün - Gegen den gebauten Server (stdio) importiert und `jdt_run_tests` aufgerufen: - `arknet-shared-kernel` (JUnit 6.1.3): junit6 korrekt erkannt, `LocalizedLiteralTest` 6/6 grün. - `fixture-core` (JUnit 5.11.4 / Platform 1.11, Temp-Kopie): junit5 korrekt erkannt, Testlauf schlägt wie oben beschrieben mit klarer Fehlermeldung fehl (Befund für #71, kein Bugfix). - Fixtures bleiben auf JUnit 5, nicht hochgezogen. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_016tHV1dzUTdTwMLgx6yotVd

hauschel.fred added 1 commit

2026-09-07 18:58:47 +00:00

fix(execution): detect JUnit test kind from project classpath ab1710d4b2

TEST_KIND was hardcoded to junit5, so projects on JUnit 4 or JUnit 6
(the product bundles loaders for all three) got the wrong launch
configuration. Detect the kind from the JUnit module jars actually
present on the project's resolved classpath instead, with a
self-healing error when no JUnit dependency is found.

Verified against arknet-shared-kernel (JUnit 6.1.3): correctly
detected junit6, 6/6 tests passed.

Also improves the timeout message when JUnit Platform 1.x (JUnit 5)
jars are present: verified against fixture-core (JUnit 5.11.4 /
Platform 1.11) that the bundled junit5.runtime loader crashes with
NoClassDefFoundError: OutputDirectoryCreator regardless of the
correctly detected test kind - a genuine incompatibility, not a
detection bug (#71). The tool result now names the mismatch instead
of a misleading "Spring context" guess; README's known-limitations
table is updated to match (JUnit 6 works, JUnit Platform 1.x does
not).

Closes #85
Refs #71

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016tHV1dzUTdTwMLgx6yotVd