Como é a sua estratégia de testes em uma aplicação full stack?

Distribua o peso por risco em vez de por dogma de pirâmide. Testes unitários para lógica pura e casos limite, uma camada sólida de testes de integração batendo em um banco de verdade dentro de um container, e um número pequeno de testes ponta a ponta cobrindo os fluxos que dão prejuízo se quebrarem, como cadastro, checkout e login. Mocke terceiros na fronteira de rede em vez de fazer stub dos seus próprios módulos.

A minha regra guia é que um teste vale a pena se ele teria pego um bug que a gente plausivelmente colocaria no ar. Lógica pura, regras de precificação, tratamento de datas, checagens de permissão, ganham testes unitários rápidos com os casos limite feios. A camada em que eu mais invisto é a de integração: requisição HTTP de verdade na aplicação, Postgres de verdade em um container, migrações de verdade, verificando a resposta e as linhas resultantes. Isso pega as coisas que os mocks escondem, como uma violação de restrição ou uma query que silenciosamente não retorna nada. Terceiros são mockados na fronteira de rede com algo como o MSW ou uma fixture gravada, nunca fazendo stub da minha própria classe de serviço, porque aí eu estou testando o mock. Ponta a ponta eu mantenho deliberadamente pequeno, umas oito jornadas cobrindo cadastro, login, checkout e o fluxo principal, rodando em todo merge. Instabilidade é a coisa com a qual eu sou implacável; um teste que falha aleatoriamente treina as pessoas a rodar o pipeline de novo, então eu conserto ou apago em até um dia. Cobertura eu olho como diagnóstico, nunca como meta.