Skip to content

YAML fixtures limited to XSL-based lints, leading to unnecessary JUnit classes for Java-implemented lints #1271

Description

@volodya-lombrozo

I cannot test Java-implemented lints (LtAsciiOnly, LtReservedName, LtIncorrectUnlint, and the new LtSyntaxVersion) the same declarative way as XSL lints, because packs/single/*.yaml only understands a sheets: key listing XSL stylesheet paths, run through Xsline in LtByXslTest.testsAllLintsByEo. There is no equivalent for a Lint implemented in plain Java, so every hand-written lint needs its own bespoke JUnit test class instead of a short input/asserts pack.

Proposed Solution

Let a pack yaml reference a lint by name instead of only by XSL sheet path, e.g.:

sheets:
  - /org/eolang/lints/metas/incorrect-version.xsl

vs.

lint: syntax-version

LtByXslTest (or a sibling test) could resolve lint: against the same lint registry MonoLints/PkMono already build, run Lint.defects(XML) directly, and reuse the existing DefectsMatcher/XtDefects assertion machinery already in place for the sheets: path.

This would let Java lints share the same lightweight, declarative test format as XSL lints, instead of requiring a new Lt*Test.java class (with EoProgram/InputOf boilerplate) for each one.

Relevant classes to investigate: LtByXslTest, XtYaml, XtDefects, MonoLints, PkMono.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestgood-titleThe title was checked and improved by ChatGPT

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions