The test pyramid only works when the architecture gives you somewhere to put unit tests. Extract conditionals out of components and the E2E count halves.

Not because the team prefers slow tests; because the architecture left them no real unit boundary. Branching logic lives inside React components alongside JSX, useEffect, and hooks. The only way to exercise a branch is to mount the component, hydrate it, and click. That is a Playwright scenario by definition. Multiply across 30 components with 5 to 10 inlined branches each and you have an inverted pyramid by accident, not by choice. The 10:1 north star is unreachable until the architecture gives you somewhere to put unit tests.

Pyramid shape is a metric on the testing layer; the cause sits one layer up, in the file tree. A team can run hackathons, set coverage gates, and ban new E2E specs, and the inverted shape returns within a sprint because the next feature ships another component with three new inlined branches and the only place to verify them is a real browser. The fix is not test policy; the fix is changing the file tree so rules live in pure functions and components do not branch on them. Once the boundary exists, the pyramid rights itself; before it exists, no policy holds.

A function whose output is determined entirely by its inputs, with no side effects, no reads from Date.now or Math.random or fetch, no DOM access, no environment-variable lookups. Same arguments yield the same answer. Anything time-dependent or runtime-dependent gets injected as an argument; the impure shell calls the pure layer. The point of purity is that the test is a literal input 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, looked at closely, is 90 percent rule and 10 percent fetch glue. The 90 percent should be pure; the 10 percent should be one integration test that proves the wires are connected.

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 designed to be. 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.

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

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.

Cleanly. An agentic tester (Assrt is one option) 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 a unit test could have proven in a millisecond. After extraction, the scenarios you hand the agent become layout, integration, and side effect checks: did the email arrive, did the webhook fire, does the page render the right reason code. Rule correctness is settled before the browser loads.

Those still belong to E2E or 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 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 billing module, src/billing/entitlements.ts and src/billing/entitlements.test.ts sit next to src/billing/PaywallGate.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.

Treat any new conditional inside JSX as a code review smell. Reviewers ask: 'is this layout or content?' If content, it belongs in a pure function. The first time a contributor extracts a single conditional into a one-line function it feels like overkill; the third time the same function gets a new branch, the team understands why the rule lives there. Code review is the cheapest tool for keeping the pyramid right-side up.

Static analysis can flag components above a branch-count threshold and suggest extraction targets. An agentic tool can do better: read the component, identify rule clusters, propose an entitlements.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 rule names and function boundaries are a design choice, not a mechanical one. The tool drafts; the human shapes.