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

Đang mở
  • Có gì không ổn?
#252 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
48/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
groovy, java, kotlin, python
Lĩnh vực
build-system, testing-qa

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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

Ngôn ngữ chính
Python
Star
4
Fork
1
Merge trung bình
10 giờ 41 phút
Pull request đã merge (30 ngày)
79

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của cpp-best-practices/project_validator

Tất cả issue của cpp-best-practices/project_validator

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.