Testing advice on the internet is written for teams of fifty engineers. Aim for high coverage, automate everything, test every function in isolation. That advice is fine at Google scale and useless for a small business app with one developer and a real budget. Follow it and you'll spend more on tests than on features. Skip testing entirely and you'll find out about bugs from customers. There's a sane middle, and it's smaller than you think.
Forget the coverage number
Code coverage measures what percentage of your code the tests touch. It's easy to measure, which is why people fixate on it, and it's a poor target. Chasing 100% means writing tests for trivial code that never breaks, and a test suite that costs hours per feature to maintain. Worse, coverage measures whether code ran during tests, not whether anything meaningful got checked.
The right question for a small app is not "what percent is covered" but "if the most important thing broke, would a test catch it before a customer does?" Budget your testing like you budget anything else: spend where the risk is.
Rank what actually matters
Every app has a handful of paths where failure costs real money or trust. For a typical small business app the list looks like:
- Customers can log in.
- Orders or bookings go through, and payment gets charged correctly.
- The data people entered yesterday is still there today.
- The invoice, quote, or report comes out with the right numbers.
- The notification emails actually send.
That's usually five to ten things. A bug in the settings page font is an annoyance; a bug in checkout is an emergency. Your testing effort should be as lopsided as those stakes.
Layer one: smoke tests on the critical paths
A smoke test answers one question: does the important stuff basically work? It's a small set of automated tests that walk the critical paths end to end. Log in as a test user. Create an order with a test payment. Pull up yesterday's record and check it's intact. Generate an invoice and check the total.
Ten to twenty of these tests cover most of the risk in a small app, and they're cheap to keep because they test behavior ("an order can be placed") rather than implementation details that change every refactor. Wire them into CI so they run on every push, and a deploy that breaks checkout gets stopped by a robot instead of reported by a customer.
Layer two: a few integration tests where the money is
Integration tests check that pieces work together: your code plus the database, your code plus Stripe, your code plus the email service. This is where small-app bugs actually live. Not in some function's logic, but in the seams: the webhook that doesn't fire, the date that changes format crossing an API, the record that saves without its line items.
You don't need many. Put them where a silent failure costs money: payment confirmation, anything that syncs to accounting, anything that calculates a price or a tax. Use each vendor's test mode (Stripe's test cards, a sandbox email address) so the tests exercise the real seam without spending real money.
Unit tests, the classic test-one-function-in-isolation kind, earn their keep in one place on a small app: genuinely tricky logic. Pricing rules, date math, commission calculations. If a function has enough branches that you'd have to think hard to check it by hand, write unit tests for it. For straightforward glue code, skip them.
Layer three: a manual release checklist
Some things aren't worth automating at small scale: does the site look right on a phone, does the PDF print cleanly, does the whole flow feel right to a human. For those, keep a written release checklist, ten to fifteen lines, and walk it before every meaningful release:
- Log in on desktop and phone.
- Place a test order with a test card, confirm the confirmation email arrives.
- Open the newest records and one old one.
- Generate this month's main report, eyeball the totals.
- Check the error log for anything new.
The checklist has to be written down. The one in the developer's head gets skipped exactly once, on the release before a long weekend, and that's the release that breaks. Fifteen minutes with a checklist beats a Saturday of firefighting every time. And when a real bug does slip through to production, add the check that would have caught it. That's how the checklist and the smoke tests earn their shape: from your app's actual failures, not from a best-practices article.
What this costs
Roughly 10 to 15 percent of the build effort, as a rule of thumb. On a project of any size that buys the smoke suite, a handful of integration tests, and the checklist. It's the difference between "we think it works" and "we checked," and it's dramatically cheaper than the alternative, which is your customers doing QA for you and telling you about it in reviews.
How to know it's done right
Deploys stop being scary. A broken critical path gets caught by CI or the checklist, not by a phone call. When a bug does reach a customer, it's in something cosmetic, not in checkout. And the test suite is small enough that it actually gets maintained instead of ignored. A modest set of tests that runs every day beats a comprehensive one that everyone stopped trusting.
Stuck on this, or want it done for you? That's the job.
Email us →