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

Aberta
  • Algo errado?
#252 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
3/5
Tempo estimado
1-2 dias
Facilidade para iniciantes
48/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
groovy, java, kotlin, python
Domínio
build-system, testing-qa

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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

Linguagem predominante
Python
Estrelas
4
Forks
1
Merge médio
10h 41min
PRs com merge (30d)
79

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de cpp-best-practices/project_validator

Todas as issues de cpp-best-practices/project_validator

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.