Verdict
Yes
Yes, a solo developer should write automated tests for the paths that customers depend on, such as signup, the core action and every saved record, and run them in CI on every push.
Why
- Blast radiususers
- Change frequencyregularly
- Detectabilityeventually
- Reversibilitywith-effort
- Test costmoderate
Yes, a solo developer should test the paths customers depend on; rule R11 gives Test for my typical case, one developer who builds and runs a web app alone for years. Blast radius is users, because customers meet the broken feature. Change frequency is regularly: each part of the app changes about once a month. Detectability is eventually, since no colleague reviews the change and a plausible wrong result waits for a customer to notice. Reversibility is with-effort, because records saved by broken code need a repair script, and Test cost is moderate, about an hour for an integration test of one path.
| When | Decision | Why |
|---|---|---|
| Only you use the code, on your own machine | Do not test; check the result after each change | Blast radius falls to none: a failure costs nobody but you |
| A client's brochure site stores nothing, and you open each changed page before you deploy | Do not test; look at each changed page in the browser | Detectability moves to immediately and Reversibility to trivial: you see the broken page, and a redeploy undoes it |
| The solo developer's app charges cards or computes invoices | Test mandatory: cover every amount and boundary in CI, and pay another developer to review those tests once | Blast radius rises to money and Reversibility to costly: a wrong charge ends in refunds |
| Each user of the app must see only their own records | Test mandatory: for each kind of record, test that one user is denied another user's records | Blast radius rises to safety-or-legal and Detectability to never: a leaked record looks like a normal page |
| The app stores nothing, and an error tracker reports each crash within minutes | Test minimally: one test of the main path, plus a regression test for each bug | Detectability moves to same-day and Reversibility to trivial: the tracker reports the crash, and a redeploy removes it |
| The core of the app syncs records from a partner API that changes without notice | Test it differently: a scheduled job that alerts you when the sync returns errors or zero records | Test cost rises to heavy: a recorded response goes stale whenever the partner changes the API |
What breaks if you don't test
You change a rule in code you wrote eight months ago, and nothing tells you that another function relied on the old behaviour. No reviewer or tester sees the change before release. The app shows a plausible wrong result, and customers find it days later. You are also the support desk, so the repair and the apology emails wait on the same person.
What you lose if you over-test
Each hour of tests comes out of support, invoices and sales. Browser tests pinned to markup break at each redesign, and nobody else fixes the selectors. Unit tests that mock the database pass while the real query fails.
How to test
- List the paths customers depend on: signup, login, the core action, and every place that saves a record.
- Write one integration test per path against a real local database, below the screens, with Vitest or pytest. Add unit tests for rules whose wrong output looks plausible: seat counts, dates, prices.
- Run the suite on every push; the GitHub Actions guide for Node.js shows the workflow file. For a solo developer, CI is the only check that sees every change.
- When a bug appears, add a regression test with the input that caused it.
When the answer changes
- The app starts to charge money or to hold records one user must not see.
- You stop adding features and fix bugs a few times a year: one test of the main path is enough.
- A client contract requires a test suite: the contract comes first.
Real incident + Code example
The waitlist that stopped moving
In my practice, I ran a booking app alone for three language schools. Eight months after I wrote the waitlist, the schools asked to see cancelled bookings, so I gave a cancelled booking a status instead of deleting it. The waitlist code, which I had forgotten, counted every booking that was not waiting as a taken seat, so a cancelled booking kept its seat. No error appeared. Twelve days later an administrator asked why a class had three empty seats and five students waiting. I promoted 14 students with a script, and two had enrolled elsewhere by then. This test fails on the broken version:
import { expect, it } from "vitest";
import { book, cancel, createClass, statusOf } from "./bookings";
it("gives a cancelled seat to the first student on the waitlist", async () => {
const cls = await createClass({ capacity: 2 });
const ana = await book(cls, "ana");
await book(cls, "ben");
await book(cls, "eva"); // the class is full, so eva waits
await cancel(ana);
expect(await statusOf(cls, "eva")).toBe("confirmed");
});
Related questions
FAQ
- What are some reasons why a sole developer should use TDD?
Test-driven development pays off for a sole developer on rules whose output is known before the code, such as seat counts, prices and dates. The test written first also records the rule for the day you return months later with nobody to ask. For screens that change every week, write tests after the screen settles.
- Do I need tests if I am the only developer?
Yes, if other people use your app, you need tests of the paths they depend on, because working alone removes code review. If only you use the code, check the result after each change instead.
- Should a freelancer write tests for client projects?
Yes, a freelancer should test, in CI, the paths a client's business depends on, such as bookings and orders. A brochure site that stores nothing needs a look at each changed page instead.
- What should a solo developer test first?
A solo developer should first test code whose wrong output looks plausible: counts, prices, dates and anything that writes records. Then add a regression test for each reported bug.