Table driven tests

Table Driven Tests

Use this skill when many inputs should exercise the same rule, parser, formatter, permission check, calculation, or state transition.

Workflow

1. Confirm every case exercises the same behavior. Split separate behaviors into separate tests before building a table.
2. Define a case structure with a descriptive name, inputs, expected result, and expected error when relevant.
3. Run each case through the same arrange, act, and assert path.
4. Give each case a stable failure label using subtests, parameter IDs, or the framework's named-case mechanism.
5. Keep per-case branching out of the assertion loop. If a case needs unique assertions, it probably deserves its own test.
6. Include representative edge cases: empty input, boundary values, invalid input, and at least one ordinary success case.

Review Checks

• A failing case name explains what broke without opening the table.
• The table is small enough to scan, or split by behavior group.
• Expected values are explicit; they are not recomputed by duplicating the code under test.
• Setup remains visible. Helpers may build data, but they do not hide the test's purpose.

Anti-Patterns

• Mixing unrelated behaviors into one large table.
• Adding if case.name == ... logic inside the assertion loop.
• Using tables to avoid writing a clear standalone test for a unique workflow.