The test pyramid inverts when components mix logic and rendering. Extract the conditionals into pure functions and the pyramid rights itself.

The classical pyramid has many fast unit tests at the base, fewer integration tests in the middle, and a small number of slow end-to-end tests at the top. An inverted pyramid is the opposite shape: few unit tests at the bottom, many E2E tests at the top, and almost nothing in the middle. Inverted pyramids are slow, flaky, and expensive to run, because every change waits on a real browser to confirm a one-line rule. Most teams arrive at this shape not by choice but by accident: they wrote components that mix logic and rendering, so the only way to verify a rule is to mount the component, which is a job for E2E.

Two reasons. First, it feels fast in the moment. The rule is small, the JSX is right there, just throw an if next to the row that displays the result. Second, frameworks make it the default. Server components, hooks, useEffect, and JSX expressions encourage you to inline a ternary or a switch directly into the tree. There is no friction asking you to extract. The friction shows up months later when the component has fifteen branches and the test file is a Playwright spec that takes twelve minutes to run.

A function whose output is determined entirely by its inputs, with no side effects, no calls to Date.now or Math.random or fetch, no access to the DOM, no reading of localStorage or environment variables. If you call it twice with the same arguments, you get the same answer. If you need a clock or a random seed, pass it in as an argument. The point of purity is that the function can be tested with a literal object and a literal expected output, no setup, no teardown, no mocks.

Split the function into two layers. The pure layer takes data and returns a decision. The impure layer fetches the data and calls the pure layer. The pure layer gets unit tested exhaustively. The impure layer gets a single integration test that verifies the wiring. Most async logic, when you look closely, is 90 percent rule and 10 percent fetch glue. The 90 percent should be pure.

It will make them shorter and simpler. A component whose only branches are layout branches reads like a template, which is what components were originally meant to be. The business logic moves to a place where the React reconciler does not need to know about it. Performance often improves because the component re-renders less. The mental model becomes: pure functions own the rules, components own the pixels, hooks own the lifecycle.

Delete most, keep a few. The E2E layer should still prove that the rule output makes it onto the screen, that the form submission triggers a recompute, and that the rendered numbers match what the rule engine returned. One happy path, one error path, and one boundary case per UI surface is usually enough. The savings come from not running the same rule branch through the browser thirty times.

Cleanly. An agentic tester like Assrt is most valuable when the E2E layer is small and intentional, because the AI is good at flexibly verifying user-visible behavior but expensive at re-proving rules that a unit test could have proven in a millisecond. After extraction, the scenarios you hand to Assrt or any other agent become layout, integration, and end-to-end side effect checks: did the email actually arrive, did the webhook actually fire, does the page render the right number. The rule correctness is settled by vitest before the agent ever loads a browser.

On a typical checkout, signup, or billing surface, somewhere between 40 and 70 percent. Anywhere there is a switch on country, role, plan, feature flag, A/B variant, or promo code, the extraction collapses many E2E branches into a single E2E case that proves the wiring plus a unit test file that proves the rules. Teams that have done this report E2E suite size cut in half and CI minutes cut by an order of magnitude on the affected modules.

Those still belong to E2E or to a dedicated visual layer. Visual regressions are not a logic concern, they are a layout concern, and pure functions cannot help with them. The benefit is that your visual tests are no longer drowning in rule-driven scenarios, so they run more often and feedback arrives faster.

Co-located with the feature, in a separate file from the component. For a checkout module, src/checkout/pricing.ts and src/checkout/pricing.test.ts sit next to src/checkout/CheckoutSummary.tsx. The unit tests live next to the function. The component imports both the function and its types. There is no shared utils dump and no global lib of business rules; each feature owns its own engine.

Yes, even more so. The same shape applies on the server: HTTP handlers and database calls are the impure shell, the rule engine is a pure function. Integration tests cover the shell. Unit tests cover the rules. The pyramid stays right-side up because the surface area for E2E shrinks to the genuinely end-to-end concerns: contracts between services, latency, retries, idempotency.

Static analysis can flag components above a certain branch-count threshold and suggest extraction targets. An agentic tool can do better: it can read the component, identify the rule clusters, and propose a pricing.ts equivalent with a paired test file. Assrt's planning layer surfaces high-branch components in a codebase as candidates for extraction; the actual refactor stays a human decision because the rule names and the function boundaries are a design choice, not a mechanical one.