The Critical Path Test Suite: A Founder's Definition

# The Critical Path Test Suite: A Founder's Definition

The critical path test suite is the minimum set of automated tests that protect the features a user must be able to complete for your product to have value. It is not the full test suite. It is not 100 percent coverage. It is the tests that, if they fail, mean the product is broken in a way that prevents users from accomplishing the core task they came to your product to do. Every production application needs this suite before anything else.

What you need to know

• The critical path is the sequence of actions a user must take to get value from your product: sign up, set up, and use the core feature
• Tests that cover the critical path protect against the most expensive category of bug: the bug that prevents revenue
• Writing these tests first, before other tests, is the highest-return testing investment available
• The critical path test suite should run on every deployment and block the deployment if it fails
• Most development teams significantly underinvest in critical path tests and overinvest in unit tests for low-stakes utility functions

The core argument

The instinct in software development is to test what you just wrote. You write a new utility function, you write a unit test for it. You write a new component, you write a unit test for it. The result is a test suite with high coverage of the code you wrote most recently and uneven coverage of the code that matters most to users. A 90 percent coverage score on a codebase does not mean that the 10 percent that is untested is unimportant. Often, the most critical user-facing logic is in the lowest-coverage parts of the codebase because it is harder to test and was written earlier, before the testing culture was established.

The critical path definition exercise forces a different starting point. Instead of "what did I write that needs tests," the question is "what must work for the product to have value." For a SaaS application, the answer is almost always: account creation, authentication, the core feature workflow, and payment processing. These four areas are the minimum scope of the critical path test suite. If any of these breaks in production, you have an incident. If your test suite catches them before production, you have a process. The difference between those two outcomes is the entire value of the critical path test suite.

The practical challenge is that critical path tests are harder to write than unit tests. They are end-to-end tests that involve multiple system components, real or mocked external services, and complex state setup. The setup cost is high enough that teams skip them in favor of faster-to-write unit tests. This is the wrong tradeoff. A unit test that passes when the database is down is not protecting you from the thing that will actually break your product. In building Nexli, I write critical path tests for the enrollment flow and attendance recording before anything else, because those are the actions that define the product's value. Everything else is tested based on the complexity and change frequency of the code.

Common mistakes

1. Defining the critical path too broadly. The critical path test suite should cover the minimum viable user journey, not every feature. If you include too many scenarios, the suite becomes slow, flaky, and expensive to maintain. A test suite that takes 30 minutes to run will not be run on every deployment.
2. Using unit tests where integration tests are needed. Critical path logic typically spans multiple components and system boundaries. A unit test that mocks the database, the authentication layer, and the payment processor is not testing whether those things work together. Use integration or end-to-end tests for critical path coverage.
3. Not including the unhappy path. The critical path test suite should test both successful and failed scenarios. What happens when payment fails? When authentication credentials are wrong? When a required field is missing? These failure paths often have bugs that are as business-critical as bugs in the success path.
4. Letting the critical path tests become flaky. A test that sometimes passes and sometimes fails is worse than no test because it trains the team to ignore test failures. Invest in making the critical path tests reliable before adding new ones.
5. Not updating the tests when the critical path changes. As the product evolves, the critical path changes. A test suite that reflects the product of six months ago is not protecting the product of today. Review and update the critical path definition whenever a major feature or user flow changes.

Where to start

Step 1: Write down the critical path in plain language. List the exact steps a new user takes from first landing on your product to completing the core action that makes your product valuable to them. This is the scope of your critical path test suite.

Step 2: Write one end-to-end test for each step in the critical path. Use a testing framework that can run against your actual application stack. For a Next.js application, Playwright is the current best choice for end-to-end tests that simulate real browser interactions.

Step 3: Block deployments on critical path test failures. In your CI/CD pipeline, run the critical path test suite on every push and block the deployment if any test fails. This is the mechanism that makes the tests valuable: not the fact that they exist, but the fact that they must pass before code reaches users.

Related reading

• The Cost of Rebuilding Trust After a Bad Launch
• The Cost of Tech Debt: A Founder's Worst Bill
• The Cost of "We Will Fix It Later": A Postmortem
• The Cost of Switching Developers Mid-Project

The Engineering Perspective Behind This Post

The work in this post is what I apply to every system I build. Yashveer Singh, founder of Yashveer Labs. The systems in production include Nexli, Nyxera, and Velmora. If your critical path is untested and you are about to ship, this is the conversation I have with every client before we touch the deployment pipeline. Instagram and the contact page are both open.