From 7c00fb4eb36d5eb3745f2761ab20b49686b905b6 Mon Sep 17 00:00:00 2001 From: Jordan Wong Date: Fri, 7 Aug 2026 13:51:03 -0400 Subject: [PATCH] skill(apm-integrations): match the sibling module's test DSL (no Java tests in a Groovy family) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Surfaced by the 2026-08-07 cache category gap sweep (jedis-3.0, reference PR #12080). jedis-3.0 is otherwise clean, but the regen wrote its tests in Java/JUnit (src/test/java, AbstractInstrumentationTest) while master and its siblings (jedis-1.4, jedis-4.0) use Groovy/Spock (src/test/groovy). Root cause is a self-contradiction in this skill file: line 7 mandates "Write Groovy/Spock tests ... Full Java instrumentation test support is not yet available", but lines ~136-175 illustrate the no-banner-comments rule with a fully Java AbstractInstrumentationTest example and nothing says which wins. The generation transcript shows the agent read the Groovy prose AND a sibling cache library's Java test (lettuce-5.0) and followed the Java exemplar. That Java choice is the direct trigger of the spurious `_dd.svc_src` CI red a prior report mis-filed as pure master-side infra: the Java DSL's TagsMatcher.defaultTags() (which carries a "// TODO Keep porting default tag logic" gap) enforces exact default tags the Groovy DSL tolerates. Fix: add an unambiguous "match the sibling module's test DSL; a Groovy family stays Groovy" rule next to the mandate, and fence the Java examples as style-only illustrations for modules already on the Java DSL — not a license to migrate a Groovy family. Domain-agnostic (all Java instrumentation), surfaced via cache but not cache-specific. Draft reference — from the toolkit eval-research thread. Co-Authored-By: Claude Opus 4.8 (1M context) --- .agents/skills/apm-integrations/references/tests.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/.agents/skills/apm-integrations/references/tests.md b/.agents/skills/apm-integrations/references/tests.md index c1be9b8cc07..6f76eed7835 100644 --- a/.agents/skills/apm-integrations/references/tests.md +++ b/.agents/skills/apm-integrations/references/tests.md @@ -6,6 +6,8 @@ **Write Groovy/Spock tests for instrumentation tests** (per `AGENTS.md`: "Only use Groovy / Spock tests for instrumentation and smoke tests"). Full Java instrumentation test support is not yet available. Adding new `.groovy` files to a PR will trigger the `Enforce Groovy Migration` bot — add the `tag: override groovy enforcement` label to bypass it. +**Match the sibling module's test DSL — do NOT introduce Java/JUnit tests into a Groovy family.** Before writing tests, `ls src/test/` on the master module you're regenerating AND on its version-sibling modules (e.g. `jedis-1.4/`, `jedis-4.0/` for `jedis-3.0`). Write the SAME DSL they use. If the siblings use `src/test/groovy/` (Spock), write Groovy — even though this file also shows Java `AbstractInstrumentationTest` examples below. Those Java examples exist ONLY to illustrate style rules (no-banner-comments, error-path coverage) for modules that are ALREADY on the Java/JUnit DSL; they are NOT a license to migrate a Groovy family to Java. Introducing a `src/test/java/**` test into a module whose siblings are `src/test/groovy/**` diverges from master's style, adds review burden, and trips the Java DSL's stricter default-tag matcher (`TagsMatcher.defaultTags()` currently omits some tags the Groovy DSL tolerates, e.g. `_dd.svc_src`), producing spurious CI failures that are NOT instrumentation defects. When in doubt, the master module's own test DSL wins. + - Groovy/Spock test class in `src/test/groovy/datadog/trace/instrumentation//` - Verify: spans created, tags set, errors propagated, resource names correct - Use `assertTraces(N) { trace(N) { span { ... } } }` for span assertions (Spock DSL from `InstrumentationSpecification`) @@ -129,7 +131,7 @@ Common libraries where this split matters: Reactor, Netty, gRPC, Kafka clients ( Do NOT insert banner-style separator comments (e.g. `// --------- Successful completion ---------`) inside test files to group related test methods. Banner comments have unclear scope, don't render usefully in IDEs, and add review burden without a benefit that justifies the noise. -**If a group of related tests warrants its own heading**, extract them into a separate test class with a focused class-level Javadoc: +**If a group of related tests warrants its own heading**, extract them into a separate test class with a focused class-level Javadoc. (The examples below are shown in Java for modules already on the Java/JUnit DSL; the same no-banner / focused-class rule applies to Groovy/Spock — do NOT read these Java snippets as instruction to write Java tests for a Groovy-family module. See the "Match the sibling module's test DSL" rule above.) ```java // ❌ Banner comments