Turn Your Examples Into Table-Driven Tests

A testing pattern where you give Claude a set of concrete input-to-output examples and ask it to generate a single table-driven (parameterized) test that runs each example as a row, rather than a separate test function per case.

When a function's behaviour is really a lookup table — this input yields that output — the clearest test is a literal table. It puts every case in one readable place, makes gaps obvious, and turns adding a case into adding a row. Claude is quick at converting a list of examples into your framework's parameterized-test idiom, and the resulting test doubles as documentation of the contract.

Pure-ish functions with many discrete cases: parsers, formatters, validators, state transitions, pricing rules. Anywhere you'd otherwise copy-paste near-identical test functions.

Tests that need different setup or assertions per case, or that check interactions and side effects rather than input-to-output mappings. Forcing those into a table makes them cryptic.

Here is the function and a set of example input→output pairs: <paste examples>.

Write a single table-driven test in <framework> where each example is a row with a short label. Use the same assertion for every row. Structure it so adding a new case is just adding a row. Include the edge cases from my examples verbatim, and flag any row where the expected output looks wrong.

You paste twelve slugify examples. Claude produces one parameterized test with twelve labelled rows. Reading the table, you immediately spot that you never specified what happens to leading numbers — a gap the flat wall of test functions would have hidden.

Keep the table itself in a data file (JSON or CSV) that both the test and the docs read from. The examples become a single source of truth: the test proves them and the documentation shows them, so they can never drift apart.

• Cramming cases with different setup or assertions into one table, producing a test full of conditionals nobody can read.
• Unlabelled rows, so a failure reports 'row 7 failed' with no clue which case that was.
• Letting Claude invent expected outputs instead of using yours — the table is only as trustworthy as the values you supplied.