Most testing advice is written for teams maintaining code for years. For a solo vibe-coded project, the goal is narrower and much easier: never fix the same bug twice, and be able to change things without fear.

Test three things

The thing that would be worst if it broke. The payment, the save, the send. One test.

Anything with fiddly logic. Date maths, pricing, permissions, parsing. This is where tests genuinely find bugs, because the rules are easy to state and easy to get subtly wrong.

Every bug you actually hit. When something breaks, write a test that fails, then fix it. That bug never comes back, and over a few months this alone gives you a test suite shaped exactly like your project's real weaknesses.

That's it. Don't test that your framework works. Don't chase a coverage number.

Why this matters more with AI

A test suite is how an agent checks its own work. Ask a model to change something in a project with tests and it can verify it didn't break anything. In a project without them, it changes the code, says "this should work", and neither of you knows.

That feedback loop is the difference between an agent that converges and one that flails.

Getting started with no setup

first-test.txt
My project: <stack>. It currently has no tests.

Set up the simplest test runner that works here — I want to run one
command and see pass or fail. Nothing else installed if avoidable.

Then write one test for this function, which is the one I'd most hate
to break: <paste>

Cover the happy path, one realistic bad input, and one edge case I
probably haven't considered. Explain what each is checking.

Then wire it into the loop

Once tests exist, tell the model about them in every session: "Run the tests after any change and fix anything you break." That one sentence changes the quality of what comes back more than any prompting technique.

A single test that runs in two seconds and catches your worst regression is worth more than a hundred tests you never run.