JVM test discovery is hard-wired to src/test/{java,kotlin} + @Test: JUnit 3 (guava-tests/test), Kotlin multiplatform jvmTest, @TestFactory, Groovy/Spock are missed

Offen
  • Stimmt etwas nicht?
#252 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
48/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
groovy, java, kotlin, python
Bereich
build-system, testing-qa

Rechercherichtung

The detection rules live in project_validator/ecosystems/jvm/tools.py (the test-path regex around lines 33-40 and the @Test pattern near line 38) and project_validator/ecosystems/jvm/init.py around line 281. Start by adding a repro fixture for each case: a @TestFactory class under src/test/java, a JUnit 3 extends TestCase file under a custom testSourceDirectory, and a src/jvmTest Kotlin file. Done when those fixtures are counted as tests and the corpus expectations for guava, okhttp and CycloneDX change.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

guava: 1107 *Test.java files under guava-tests/test (JUnit 3, extends TestCase) → "no tests found"; okhttp: src/jvmTest (117 of 199 files missed); kotlinx.coroutines: 496 test files counted as 1; CycloneDX: JUnit 5 @TestFactory dynamic tests → "no tests found"; liquibase: 392 Spock specifications (.groovy, unrecognised) vs 170 Java files counted. Discover by source-set convention (src/*Test/, Maven testSourceDirectory, *-tests/test), @TestFactory/@ParameterizedTest, extends TestCase, and Groovy as a JVM language.

Evidence from the corpus audit

CycloneDX/specification / tests-run (JVM)
  • kind: FALSE_NEGATIVE
  • actual: FAIL: JVM: no tests found (@Test methods or Kotest specs under src/test/java or src/test/kotlin)
  • expected: PASS: tools/src/test/java holds three JUnit 5 test classes (dynamic tests via @TestFactory) and CI
    runs mvn clean test in tools (the answers dump already has the Java unit at "answer": "yes", level runs,
    but "defined": {}).
  • evidence: tools/src/test/java/org/cyclonedx/schema/JsonSchemaVerificationTest.java:42:
    import org.junit.jupiter.api.TestFactory; and :93: @TestFactory; same at
    XmlSchemaVerificationTest.java:73, XmlCatalogVerificationTest.java:42; .github/workflows/test_java.yml:37:
    run: mvn clean test. Validator project_validator/ecosystems/jvm/tools.py:38:
    r"@(?:org\.junit\.(?:jupiter\.api\.)?)?Test\b" — @TestFactory has no word boundary after Test, and
    @ParameterizedTest, @RepeatedTest, @TestTemplate are not matched either. The facts dump has 0 TestFile
    facts for the repository.
  • repro: src/test/java/ATest.java containing only @TestFactory Stream<DynamicTest> t() {…}, CI mvn test.
    Accept @(ParameterizedTest|RepeatedTest|TestFactory|TestTemplate) (and @Test\b).
  • confidence: high
google/guava, square/okhttp, Kotlin/kotlinx.coroutines / tests-run
  • kind: FALSE_NEGATIVE
  • actual: guava FAIL: JVM: no tests found (@Test methods or Kotest specs under src/test/java or src/test/kotlin);
    okhttp Java in the root: tests found in 46 file(s) / Kotlin in the root: tests found in 46 file(s);
    kotlinx.coroutines JVM: tests found in 1 file(s), but no CI configuration runs mvn test or gradle test
  • expected: guava PASS (1107 *Test.java files, CI runs mvn verify); okhttp ~199 test files; coroutines 496 test
    files (no CI, so WARN is right but the count is wrong by two orders of magnitude)
  • evidence:
    • guava pom.xml:149-150: <sourceDirectory>src</sourceDirectory> / <testSourceDirectory>test</testSourceDirectory>
      (tests live in guava-tests/test/com/google/common/..., 1107 files; grep -c "public void test" guava-tests/test/com/google/common/base/StringsTest.java = 21, JUnit 3 extends TestCase, no @Test)
    • guava .github/workflows/ci.yml:56: run: ./mvnw -B -P!standard-with-extra-repos -Dtoolchain.skip verify -U -Dmaven.javadoc.skip=true -Dsurefire.toolchain.version=${{ matrix.java }} -f $ROOT_POM
    • okhttp: 117 of 199 test files are under okhttp/src/jvmTest/ and 12 under okhttp/src/commonTest/ (Kotlin Multiplatform source sets); .github/workflows/build.yml:115: run: ./gradlew test allTests -Ptest.java.version=${{ matrix.java-version }}
    • coroutines: 162 test files under kotlinx-coroutines-core/jvm/test, 148 under kotlinx-coroutines-core/common/test
    • validator project_validator/ecosystems/jvm/tools.py:33-40: path=re.compile(r"(?:^|/)src/test/(?:java|kotlin)/.+\.(?:java|kt)$"), contains=re.compile(r"@(?:org\.junit\.(?:jupiter\.api\.)?)?Test\b|...Spec\b")
  • repro: pom.xml with <build><testSourceDirectory>test</testSourceDirectory></build>, test/FooTest.java containing
    public class FooTest extends TestCase { public void testX() {} }, workflow step run: mvn verify; and a KMP module
    with src/jvmTest/kotlin/FooTest.kt containing @Test
  • confidence: high
liquibase/liquibase / detection (Groovy/Spock)
  • kind: DETECTION
  • actual: map unrecognised_suffixes: .groovy 392 files; tests-run "JVM: tests found in 170 file(s)"
  • expected: Groovy recognised as a JVM language; the Spock specifications under src/test/groovy are the bulk of the
    unit tests (392 files vs 170 Java test files)
  • evidence: liquibase-standard/src/test/groovy/liquibase/change/core/ (40 files), .../util/ (30 files);
    validator ecosystems/jvm/__init__.py:281: # Kotlin and Groovy scripts are mostly Gradle builds and their helpers, which name no language.
  • repro: src/test/groovy/FooSpec.groovy with class FooSpec extends Specification
  • confidence: medium

Found by the regression-corpus audit (235 real repositories, one or more per ecosystem profile; corpus and expected results in corpus/). Evidence is quoted from the audited checkouts at the commits pinned in corpus/projects.toml; <checkouts>/<owner>__<repo> is such a checkout.

🤖 Generated with Claude Code

https://claude.ai/code/session_01ByTXNqDWdM7HzezrFtEvQt

Vorherrschende Sprache
Python
Sterne
4
Forks
1
Ø Merge
10 Std. 41 Min.
Gemergte PRs (30 T.)
79

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus cpp-best-practices/project_validator

Alle Issues in cpp-best-practices/project_validator

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.