Most teams approach automated testing for SaaS backwards. They chase a coverage number, write a thousand tests that all pass, and still ship the bug that takes down checkout on a Friday. The goal was never 100 percent coverage. The goal is fast, reliable tests on the handful of paths that would actually hurt if they broke. Everything else is optional, and a lot of it is noise that slows you down. This is how to decide what to test, what to skip, and why the difference matters more than the total.
The reason this gets confused is that coverage is easy to measure and value is hard to measure. So people optimize the thing they can see. A test suite at 90 percent coverage feels safer than one at 50 percent. But coverage tells you which lines ran during a test. It tells you nothing about whether the test would catch a real failure, or whether the line mattered in the first place. You can hit 90 percent by testing getters and setters and never touch the one flow that moves money.
Start with what would hurt if it broke
Before you write a single test, list the things that cannot break. Not “should not.” Cannot. For most SaaS products that list is short and obvious once you say it out loud:
- Signup and login. If people cannot get in, nothing else matters.
- Billing and anything that touches money. Charges, upgrades, downgrades, cancellations.
- The core action your product exists to do. The one thing a user pays you for.
- Data integrity on writes. Anything that could silently corrupt or lose customer data.
- Permissions and tenant isolation. One customer seeing another customer’s data is a company-ending bug.
That is your priority list, ranked by blast radius. These paths deserve the most thorough, most reliable tests you have. If a test on one of these is flaky, you fix it that day, because a flaky test on checkout is worse than no test at all. It trains the team to ignore red.
Everything below this line is a different category. Settings pages, secondary views, admin panels nobody touches, edge cases on features three customers use. These can break, get noticed, and get fixed without anyone losing trust in your product. Test them if it is cheap. Skip them if it is not. The asymmetry is the whole point. A broken login costs you the business. A broken “export to CSV” button costs you a support ticket.
What to skip on purpose
Skipping is a skill. Here is what I tell teams to deprioritize or drop:
Implementation detail tests. If a test breaks every time you rename a function or refactor internals, it is testing how the code works, not what it does. These tests punish the exact thing you want to encourage, which is cleaning up code. Test behavior and outputs, not the shape of the implementation underneath.
Tests for code that barely runs. That clever fallback for a config that has never been null in production. The migration path for a feature you are about to delete. Coverage will reward you for testing these. Reality will not.
Snapshot tests that nobody reads. A snapshot test that fails and gets blindly re-recorded is not a test. It is a ritual. Either someone reads the diff and decides, or the test is theater.
Exhaustive unit tests on glue code. Controllers that just wire three things together rarely benefit from heavy unit testing. A single integration test that exercises the real path catches more than ten unit tests on the wiring.
The mindset shift is that fewer, sharper tests beat a wall of weak ones. Every test you write is something you have to maintain, debug when it flakes, and wait on in CI. A test that never catches a bug is pure cost. Be willing to delete tests. A suite you trust at 50 percent meaningful coverage will serve you better than one you ignore at 95 percent.
Speed and reliability are features of the suite
A test suite has two jobs beyond catching bugs: it has to be fast enough that people run it, and reliable enough that people believe it. Miss either and the suite stops working as a safety net, no matter how many tests it has.
Speed matters because a slow suite changes behavior. If tests take 20 minutes, people stop running them locally, batch up changes to avoid the wait, and merge on faith. That is the opposite of what you want. Smaller, more frequent changes are safer, and a fast suite is what makes small changes practical. If yours is dragging, the fix is usually structural, not “add more machines.” The short version: most of your tests should be fast unit and integration tests, and only the critical paths need slow end-to-end coverage.
Reliability matters even more. A flaky test, one that passes and fails on the same code, is worse than no test, because it teaches the team that red does not mean broken. Once people start re-running CI until it goes green, the suite is dead. It still runs. It just no longer means anything. If you have flakes, treat them as the emergency they are. The rule I hold: a test on a critical path is never allowed to be flaky. Quarantine it or fix it, but do not leave it red-sometimes on checkout.
This is why “what to skip” and “keep it fast and reliable” are the same conversation. Every test you skip is time and flake risk you do not pay for. Pruning the suite is how you keep the part that matters trustworthy.
Unit, integration, end to end: where each earns its place
You do not pick one. You use each where it is strongest.
Unit tests are for logic with branches. Pricing calculations, date math, permission rules, anything with enough conditions that you want to prove each one. They are fast and precise, and they point straight at the broken thing. Spend them on real logic, not on glue.
Integration tests are the workhorse for SaaS. They exercise a real path through several pieces, an API endpoint hitting a real database, a service talking to a queue, without booting the whole app and a browser. This is usually the best return on effort. Most of your meaningful coverage should live here.
End to end tests drive the actual product the way a user does, through the real UI. They are the only thing that proves the whole stack works together, and they are also the slowest and flakiest to maintain. So you ration them. Reserve end to end coverage for the critical paths from the first section, the ones where “the API returned 200 but the button did nothing” is a real failure mode you have to catch.
That last gap, between a passing backend test and a UI that is actually broken, is where a lot of production bugs hide. It is also the hardest thing to automate the old way, because traditional end to end tests are brittle and break on every layout change. The newer approach is to have an agent drive a real browser against your acceptance criteria, which is more resilient than hard-coded selectors and catches the things assertions miss. That is how we close the gap inside Railflow, with browser-driven QA against the spec instead of a giant fragile end to end suite.
How testing fits the delivery loop
Tests are not a phase you do at the end. They are part of how work moves from idea to production, and where they sit changes how much they help.
This is the bottleneck most teams miss. AI coding assistants made writing code faster, but delivery did not speed up to match, because the slow part was never the typing. It was the gaps between planning, building, testing, and shipping. Testing is one of those gaps, and it is the one teams most often treat as a manual chore bolted on at the end. So it gets skipped under deadline pressure, exactly when the risk is highest.
Inside Railflow, testing is a built-in stage, not an afterthought. The factory runs a four-stage loop with a human approving each step. Plan turns feedback, bug reports, and recordings into a real spec with acceptance criteria. Build writes production-ready code on its own branch and PR, with generated tests, matching the team’s existing style. Then the Test stage runs real browser QA against every one of those acceptance criteria, captures screenshots and a screen recording of any bug it finds, and flags the moment a criterion fails. Only after that does anything reach Deploy.
Two things make this work, and both apply whether or not you use a tool like ours. First, the tests are tied to acceptance criteria written during planning, so you are testing what the change was supposed to do, not whatever happened to be easy to assert. Second, a human reviews and approves before each stage moves on. Speed without control is a liability, and the place you most want a human in the loop is right before something risky ships. Automated testing is leverage, not a replacement for judgment.
There is a quality dimension too. Shipping fast without discipline leads to feature dilution, the fast fashion era of SaaS where teams pile on features nobody asked for. Tying tests to acceptance criteria, and acceptance criteria to actual customer signal, is part of how you ship fast and ship the right things. The test suite is not just a bug net. It is a record of what your product is supposed to do.
A simple rule to take away
When you are deciding whether to write a test, ask one question: if this broke in production, would I lose sleep? If yes, test it well, keep it fast, and never let it go flaky. If no, test it cheaply or skip it and move on.
That single filter will do more for your automated testing than any coverage target. It points your effort at the paths that carry real risk, keeps the suite small enough to stay fast, and keeps it trustworthy enough that a red build actually means something. Coverage is a vanity number. Confidence is the goal. Build the suite that lets you ship a small change on a Friday afternoon without holding your breath, and skip the rest without guilt.