Perl: t/, xt/, inc/ and corpus/ are not auxiliary roles; `./Build authortest` runs the tests; Test::Perl::Critic in the tests is perlcritic; Test::Warnings in test classes

Offen
  • Stimmt etwas nicht?
#269 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
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
40/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
perl, python
Bereich
devtools

Rechercherichtung

The Perl rules live in project_validator/ecosystems/perl.py: the tests-run command prefixes near line 61, PERLCRITIC and PERLCRITIC_ANALYZER around lines 153-203, and PERL_TEST_SETTINGS near line 164. Reproduce each false negative with the repro fixtures described in the issue (a Build.PL with a t/basic.t, an xt/critic.t using Test::Perl::Critic, and a t/lib module using Test::Warnings) and check the results against the corpus expectations. Done means those cases pass without changing the existing verdicts for other Perl projects in the corpus. Whether a Test::Perl::Critic author test should satisfy static-analysis is an open design question the maintainers should settle first.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Perl-Critic: FAIL "no CI runs prove -l t (or make test, ./Build test, dzil test)" though every job runs ./Build authortest, a Module::Build action defined in the repo that depends on test; static-analysis FAIL "perlcritic configured but does not run" though the author tests run Test::Perl::Critic (the profile doc says that counts); tidyall's test classes use Test::Warnings (fails any test on a warning) but the reader scans only *.t. The roles table lacks Perl's t/, xt/, inc/ (bundled), corpus/ (Dist-Zilla's test distributions), so fixtures fail compiler-warnings for all four projects.

Evidence from the corpus audit

Perl-Critic/Perl-Critic / tests-run
  • kind: FALSE_NEGATIVE
  • actual: FAIL: Perl: tests found in 50 file(s), but no CI configuration runs prove -l t (or make test, ./Build test, dzil test)
  • expected: PASS: every CI job runs ./Build authortest, a Module::Build action defined in the repository that depends
    on test and adds xt to the test files.
  • evidence: .github/workflows/testsuite.yml:31: run: ./Build authortest (also lines 79, macOS, windows jobs);
    inc/Perl/Critic/Module/Build/Standard.pm:17-21: sub ACTION_authortest { ... $self->depends_on('test');;
    inc/Perl/Critic/Module/Build/Standard.pm:78-79: $self->test_files( qw< t xt > ); /
    $self->recursive_test_files(1);; validator project_validator/ecosystems/perl.py:61: prefixes = (("prove",), ("make", "test"), ("Build", "test"), ("perl", "Build", "test"), ("dzil", "test")).
  • repro: Build.PL + t/basic.t + workflow step run: ./Build authortest → WARN/FAIL (reproduced in repro-perl).
    Minimal fix direction: accept Build <action> when inc/**/*.pm defines sub ACTION_<action> that
    depends_on('test'), or at least authortest/testall/testcover (Module::Build's own test actions).
  • confidence: high
Perl-Critic/Perl-Critic / static-analysis
  • kind: FALSE_NEGATIVE
  • actual: FAIL: Perl: perlcritic is configured (examples/perlcriticrc, perlcriticrc) but does not run
  • expected: PASS: the author tests run Test::Perl::Critic over the code, and ./Build authortest runs them in every
    job; the Perl profile doc says "perlcritic runs in CI (or Test::Perl::Critic in the tests)" and compiler-warnings for
    the same project reports found perlcritic.
  • evidence: xt/40_criticize-code.t:28: eval 'use Test::Perl::Critic; 1;'; .github/workflows/testsuite.yml:31:
    run: ./Build authortest; validator project_validator/ecosystems/perl.py:197-203 PERLCRITIC_ANALYZER only
    accepts commands starts(("perlcritic",), ("tidyall",)), while PERLCRITIC (line 153-157) accepts the
    use Test::Perl::Critic pattern for compiler-warnings. Secondary: examples/perlcriticrc is an example file under
    examples/ named as the project's configuration.
  • repro: xt/critic.t with use Test::Perl::Critic; + workflow run: prove -l xt → static-analysis says perlcritic
    does not run.
  • confidence: high (medium on whether a Test::Perl::Critic author test should satisfy static-analysis; the doc says so)
houseabsolute/perl-code-tidyall / warnings-as-errors
  • kind: FALSE_NEGATIVE
  • actual: FAIL: Perl: warnings are not treated as errors in the modules and the tests
  • expected: PASS: the test classes (Test::Class::Most modules loaded by every t/*.t) use Test::Warnings, which fails
    a test on any warning; the reader only scans *.t.
  • evidence: t/lib/TestFor/Code/TidyAll/Basic.pm:15: use Test::Warnings; (same in the other 17 t/lib/TestFor/**
    modules); t/Basic.t loads it; validator project_validator/ecosystems/perl.py:164:
    PERL_TEST_SETTINGS = requirement_reader("Perl tests", ("*.t",), (PERLCRITIC, TEST_WARNINGS)).
  • repro: t/lib/TestFor/Foo.pm with use Test::Warnings; + t/foo.t with use TestFor::Foo; → FAIL.
  • confidence: medium (requires reading .pm under t/ as test code, which is again the t/ role question)

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.