Parameterized test / table-driven test
One test body run against a table of named inputs and expected outputs, giving repeated cases less copy-paste and clearer failures.
See it
What it is
A parameterized test defines one test body and runs it once for each named row of inputs and expected results. Vitest and Jest call the pattern test.each, JUnit has parameterized tests, and Go developers usually call the same shape table-driven tests. The table removes repeated setup without hiding which examples were checked.
Reach for it when several cases exercise exactly the same behavior: date formats, pricing bands, validation limits, status-code mappings. Give every row a descriptive name and keep the expected value beside its inputs so a failure report says which rule broke.
Gotcha: one table can become a junk drawer for cases with different setup or different claims. If rows need flags that change the test body, split them into separate tests. And do not mistake ten handpicked rows for exhaustive coverage of a large input space.
Ask AI for it
Refactor these repeated Vitest cases into test.each. Define a typed table whose rows contain name, input, and expected output, include the case name in the generated test title, and keep one arrange-act-assert body for every row. Preserve each existing behavior, add the documented empty and boundary cases, and split out any case that needs different setup or expects a different kind of result instead of adding control flags to the table.