A team's test suite is slow, flaky and gives little confidence. What shape should the strategy have, and what determines it?

What determines the shape

Not a prescribed pyramid but where the risk actually is. A system whose complexity is in domain logic needs many unit tests; one whose complexity is in integration and state synchronisation needs the weight higher up. Applying a standard shape regardless of where the risk lives produces a suite that tests the easy parts thoroughly and the dangerous parts not at all.

The question to ask: what has actually broken, and would a test have caught it? Reviewing the last twenty production defects and asking which level of test would have caught each one produces a better strategy than any general principle.

The specific problems and their causes

• Slow usually means too many tests at too high a level, each starting infrastructure. The fix is pushing logic down into units that can be tested without I/O, which is a design change rather than a testing one.
• Flaky almost always means a test depending on timing, shared state or ordering. Flaky tests are worse than no tests, because they train the team to re-run until green — which discards the signal from the genuine failures too. The correct response is to fix or delete, immediately, never to retry.
• Low confidence means the tests do not exercise what breaks. Frequently the suite tests implementation details thoroughly and behaviour barely, so it fails on refactoring and passes on regressions.

What to test at each level for a local-first product

• Unit: the merge and conflict-resolution logic, which is pure, complex, and where correctness is expensive.
• Integration: the sync protocol against a real server, including reconnection, partial failure and out-of-order delivery.
• End-to-end: a small number of critical journeys, and specifically the multi-client scenarios — two devices, one offline, both editing — which is where the product's hardest behaviour lives and which no lower-level test covers.

The economics that decide the top of the suite

End-to-end tests are expensive to write, slow to run and the most likely to be flaky. They are worth it only for journeys where failure is unacceptable, and the correct number is a small one chosen deliberately — not whatever accumulated.