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

Ouverte
  • Quelque chose ne va pas ?
#252 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
48/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
groovy, java, kotlin, python
Domaine
build-system, testing-qa

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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

Langage dominant
Python
Étoiles
4
Forks
1
Merge moyen
10 h 41 min
PR mergées (30 j)
79

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de cpp-best-practices/project_validator

Toutes les issues de cpp-best-practices/project_validator

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.