Generate table-driven unit tests for a function with edge cases

Writing the first batch of tests for a function is tedious, and it's exactly where people skip the boring-but-important cases: empty inputs, boundaries, error paths. This prompt produces a table-driven suite—one parameterized structure with many cases—so the tests stay readable and easy to extend. It deliberately tells the model to test observable behavior, not private internals, which keeps the tests from breaking every time you refactor. By asking for a one-line rationale per case and a list of cases it could not test, you get insight into the function's testability, not just code. Give it the framework you actually use (pytest, Jest, JUnit, Go's testing package) so the syntax matches your project, and name any external dependencies that need mocking. Treat the result as a strong starting suite: review the expected values, since the model infers them from the code and can inherit a bug if the code itself is wrong. It pairs naturally with the refactoring prompt as your before-and-after safety net.

What you can expect back

```python
import pytest
from slugs import slugify

@pytest.mark.parametrize('text, expected', [
    ('Hello World', 'hello-world'),      # happy path
    ('  spaced  out  ', 'spaced-out'),   # collapses repeated whitespace
    ('UPPER', 'upper'),                  # lowercases
    ('single', 'single'),                # no separators needed
])
def test_slugify_returns_expected(text, expected):
    assert slugify(text) == expected

@pytest.mark.parametrize('bad', ['', None])
def test_slugify_rejects_empty(bad):
    with pytest.raises(ValueError):
        slugify(bad)
```

Cases I could not fully test:
- Unicode/accented input: behavior is undefined in the code—confirm intended output before asserting.
- None is passed to `.lower()` only after the empty check; verify None is meant to raise ValueError, not TypeError.

Illustrative example — your results will vary by tool and inputs.

Get sharper results

• 01Read every expected value—the model derives them from the code, so a bug in the code becomes a bug in the test.
• 02Name your framework precisely (e.g. 'pytest with parametrize') to avoid getting unittest-style boilerplate.
• 03Ask for property-based tests as a follow-up for functions with large input spaces.
• 04If a case is marked untestable, that's often a hint the function needs a clearer contract.

Adapt it for your case