# Table Driven Tests

> Use when one behavior should be checked against many input and output cases. Put cases in a named table and run the same assertion path.

- Skill: `selamy-labs/table-driven-tests` (Agent Skill)
- Install (CLI): `npx skillmds@latest add selamy-labs/table-driven-tests`
- Raw SKILL.md: https://api.skillmd.com/api/skills/selamy-labs/table-driven-tests/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: selamy-labs (https://skillmd.com/u/selamy-labs)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/selamy-labs/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.