tdd

Current test setup

!cat package.json 2>/dev/null | grep -A3 '"scripts"' | grep -i test

Instructions

Follow this loop for the task at hand. Do not skip steps even if the fix looks obvious — the point of TDD is catching the cases where it wasn't as obvious as it looked.

1. Understand the requirement before writing anything

State in one or two sentences what behavior you're about to implement or fix, and what the observable success criterion is (a specific input → expected output, not "it works"). If the requirement is ambiguous, ask before writing a test for the wrong behavior.

2. Write the test first

• Write the smallest test that would fail against the current code, expressing the requirement from step 1.
• Follow the existing test file's conventions (framework, assertion style, file location) — check a sibling test file before assuming.
• For a bug fix: the test must reproduce the bug. If you can't write a test that fails against the current buggy code, you haven't isolated the bug yet — go back to step 1.
• Don't write multiple unrelated tests at once. One behavior, one test, one loop iteration.

3. Run the test and confirm it fails for the right reason

Run just this test (not the whole suite) and read the failure output. Confirm:

• It fails (not erroring out on a typo or missing import).
• It fails because the behavior doesn't exist yet — not because of a setup mistake in the test itself.

If it passes immediately, the test isn't testing what you think it's testing. Fix the test before writing any implementation code.

4. Write the minimum implementation to pass

Implement only enough to make this test pass — resist the urge to also handle cases the test doesn't cover yet. Over-implementing ahead of a test is how untested branches sneak in.

5. Run the test again and confirm it passes

Run the same single test. If it doesn't pass, debug the implementation, not the test (don't loosen the assertion to make it pass unless you've confirmed the assertion itself was wrong in step 3).

6. Run the full test suite

Confirm you haven't broken anything else. If something else broke, that's real signal — fix it, don't suppress it.

7. Refactor with the safety net in place

Now that the behavior is locked in by a passing test, clean up: remove duplication, improve naming, simplify control flow. Re-run the test suite after refactoring, not just the new test.

8. Report

State which test(s) you added, what they cover, and confirm the full suite is green. If you skipped writing a test for any part of the change (and explain why), say so explicitly rather than letting it pass silently.