migrate-junit-source-to-tabletest

Goal: Migrate JUnit 5 parameterized tests using @MethodSource/@CsvSource/@ValueSource to @TableTest with minimal churn and passing tests. Process (do in this order): 1) Locate targets via Grep (no agent subprocess). Search for: "@ParameterizedTest", "@MethodSource", "@CsvSource", "@ValueSource". 2) Read all matching files up front (parallel is OK). 3) Convert eligible tests to @TableTest. 4) Write each modified file once in full using Write (no incremental per-test edits). 5) Run module tests once and verify "BUILD SUCCESSFUL". If failed, inspect JUnit XML report. Import: `import org.tabletest.junit.TableTest;` JDK 8 rules: - No text blocks. - @TableTest must use String[] annotation array syntax: ``` @TableTest({ "a | b", "1 | 2" }) ``` Table formatting rules (mandatory): - Always include a header row (parameter names). - Always add a "scenario" column; using common sense for naming; scenario is NOT a method parameter. - Use '|' as delimiter. - Align columns with spaces so pipes line up vertically. - Prefer single quotes for strings requiring quotes (e.g., 'a|b', '[]', '{}', ' '). - Use value sets (`{a, b, c}`) instead of matrix-style repetition when only one dimension varies across otherwise-identical rows. Conversions: A) @CsvSource - Remove @ParameterizedTest and @CsvSource. - If delimiter is '|': rows map directly to @TableTest. - If delimiter is ',' (default): replace ',' with '|' in rows. B) @ValueSource - Keep single-parameter tests on `@ValueSource` (and `@NullSource` when null cases are needed). - Otherwise convert to @TableTest with header from parameter name. - Each value becomes one row. - Add "scenario" column using common sense for name. C) @MethodSource (convert only if values are representable as strings) - Convert when argument values are primitives, strings, enums, booleans, nulls, and simple collection literals supported by TableTest: - Array: [a, b, ...] - List: [a, b, ...] - Set: {a, b, ...} - Map: [k: v, ...] - `@TableTest` and `@MethodSource` may be combined on the same `@ParameterizedTest` when most cases are tabular but a few cases require programmatic setup. - In combined mode, keep table-friendly cases in `@TableTest`, and put only non-tabular/complex cases in `@MethodSource`. - If `@TableTest` is not viable for the test at all, use `@MethodSource` only. - For `@MethodSource`, name the arguments method `<testMethodName>Arguments` (camelCase, e.g. `testMethodArguments`) and return `Stream<Arguments>` using `Stream.of(...)` and `arguments(...)` with static import. - Blank cell = null (non-primitive). - '' = empty string. - For String params that start with '[' or '{', quote to avoid collection parsing (prefer '[]'/'{}'). D) @TypeConverter - Use `@TypeConverter` for symbolic constants used by migrated table rows (e.g. `Long.MAX_VALUE`, `DDSpanId.MAX`). - Prefer explicit one-case-one-return mappings. - Prefer shared converter utilities (e.g. in `utils/test-utils`) when reuse across modules is likely. Scenario handling: - If MethodSource includes a leading description string OR @ParameterizedTest(name=...) uses {0}, convert that to a scenario column and remove that parameter from method signature. Cleanup: - Delete now-unused @MethodSource provider methods and unused imports. Mixed eligibility: - Prefer combining `@TableTest` + `@MethodSource` on one `@ParameterizedTest` when only some cases are complex. Do NOT convert when: - Most rows require complex builders/mocks. Test command (exact): ./gradlew :path:to:module:test --rerun-tasks 2>&1 | tail -20 - If BUILD FAILED: cat path/to/module/build/test-results/test/TEST-*.xml