See ../AGENTS.md for project-specific guidance for AI coding assistants contributing to Apache Groovy, including ASF licensing and provenance requirements.
Groovy tests many methods inline: a <pre class="...groovyTestCase"> block inside a Javadoc/GroovyDoc comment is extracted and executed as a real JUnit test by groovy.test.JavadocAssertionTestSuite (src/test/groovy/MainJavadocAssertionTest.groovy for src/main; subprojects have their own *JavadocAssertionTest). This is the standard test form for the GDK (DefaultGroovyMethods, ArrayGroovyMethods, and similar) — the worked assert examples in a method's Javadoc are its test suite.
Therefore, when a change adds or contains groovyTestCase Javadoc blocks covering the new behaviour, do not flag it as “missing tests” or “no accompanying unit tests” — the tests are present and run in CI. Only flag genuinely untested behaviour (no groovyTestCase block and nothing else exercising it). Canonical detail: see “Inline Javadoc tests” in ../CONTRIBUTING.md.
Tests under src/spec/test/ (and subprojects/<module>/src/spec/test/) are executable examples include::'d into the user-facing AsciiDoc docs; they run as real tests. They are deliberately curated to read as documentation — clear, representative examples, usually the happy path. Error cases, edge cases, extra coverage, and regression tests for tracked bugs typically live in the ordinary src/test/ tree instead.
Therefore: a spec test is that behaviour's coverage. Do not flag a spec example as “untested”, and do not request that spec coverage be duplicated in src/test/. Only ask for additional src/test/ coverage for behaviour (error/edge cases) genuinely not exercised anywhere. Canonical detail: see “Executable AsciiDoc examples” in ../CONTRIBUTING.md.