Testes Automatizados: A Cultura Pragmática B2B (Playwright e Vitest)
Índice do Manual
Construir um SaaS B2B exige uma corda bamba quase impossível: Go-to-Market Agressivo (velocidade de entrega) contra Zero Downtime Corporativo (evitar que um bug derrube a operação do cliente).
A maioria dos desenvolvedores adota estratégias de testes extremas. Ou não testam nada e rezam na sexta-feira, ou adotam regras acadêmicas que exigem "100% de cobertura", paralisando a equipe.
Neste manual, implementamos a Estratégia de Qualidade Pragmática. Sem dogmas acadêmicos, focada apenas em proteger o caixa da empresa.
1. Onde os Testes Entram no Nosso Dia 1?
Na nossa arquitetura, os testes não são rodados manualmente pelo programador. Eles atuam como um Guardião do Portão invisível, configurados no Dia 1 do projeto:
- O Primeiro Muro (Local): Utilizamos o Husky (Git Hooks). Ao tentar fazer um
git commit, os testes unitários (Vitest) são disparados instantaneamente na sua máquina. Se o código quebrar matemática ou regras de negócio, o commit é abortado. O código sujo não entra nem no histórico. - O Segundo Muro (CI/CD): Quando você abre um Pull Request para a branch de homologação (
staging), o GitHub avisa a Vercel, que sobe uma URL temporária idêntica à produção. É aqui que os Testes E2E (Playwright) entram em ação no GitHub Actions, abrindo navegadores invisíveis e tentando quebrar essa URL. Se o robô não aprovar, o botão de "Merge" fica vermelho e bloqueado.
2. TDD vs Funcionalidade Primeiro: A Quebra do Mito
Existe uma regra sagrada na nossa esteira de desenvolvimento: Nós dividimos a abordagem dependendo da camada da stack.
A Camada Visual (Next.js / Frontend) = Funcionalidade Primeiro
Fazer TDD (Test-Driven Development) em telas de SaaS rápido é jogar dinheiro fora. Botões mudam de lugar, fluxos são alterados por decisão de design ou AB tests.
- A Prática: Você monta a tela inteira, valida visualmente se a UX está fluida, e só depois escreve um Teste E2E "por cima" dela, apenas para garantir que a navegação não quebre futuramente.
A Camada de Dados (Supabase / Backend) = TDD (Teste Primeiro)
Regras de imposto, restrições de RLS (segurança de quem lê o quê) ou cálculos de juros não aceitam margem de erro.
- A Prática: Aqui o TDD brilha. Antes de escrever a lógica de backend, você escreve o teste unitário (Vitest) exigindo o resultado correto. Você roda o teste, o teste falha (porque a função não existe). Então, você programa a função até o teste passar.
3. E o BDD? Quando ele serve e por que o ignoramos?
O BDD (Behavior-Driven Development) tenta escrever testes em formato de história ("Dado que sou um usuário, quando clico em comprar, então vejo sucesso").
Quando o BDD faz sentido? Ele é excelente para equipes gigantes onde há uma separação estrita de papéis: Gerentes de Produto (PMs) que não sabem programar, Analistas de Negócios e equipes de Qualidade (QA) dedicadas. O BDD serve como uma "língua universal" para que pessoas não-técnicas possam ler e aprovar as regras de negócio antes mesmo do código existir.
Veredito para a Nossa Stack: Para equipes técnicas focadas (Desenvolvedores Full-Cycle, Tech Leads ou especialistas solo), o BDD é pura burocracia. O BDD exige que você escreva o teste em "Português", instale uma ferramenta complexa (Cucumber) que lê o português, e depois crie o script de código que mapeia esse português para a automação.
Na nossa stack, escrevemos os testes de ponta a ponta (E2E) diretamente em código moderno usando Playwright, que é limpo o suficiente para ser lido organicamente, sem a camada desnecessária do BDD.
4. O Cenário Ideal: Os Dois Pilares da Nossa Arquitetura
Nós não buscamos 100% de cobertura de código. Nós buscamos 100% de Cobertura do Caminho Crítico (Critical Path). Você só precisa automatizar testes para aquilo que sangra dinheiro se quebrar.
Pilar 1: Testes E2E com Playwright (O Robô)
O Playwright assume o controle de um Google Chrome sem tela, navegando pelo seu SaaS como se fosse um humano.
- O Alvo: As 5 rotas que geram dinheiro.
- A Obrigação:
- O Fluxo de Login B2B (Se quebrar, o cliente processa você por indisponibilidade).
- O Fluxo de Pagamento/Checkout no Stripe (Se quebrar, a empresa não fatura).
- A ação principal (Criar a fatura, emitir a nota, aprovar o contrato).
- Se a página "Editar Cor do Perfil" quebrar, é um inconveniente. Se o Login quebrar, é uma crise. O Playwright blinda a crise.
Pilar 2: Testes Unitários com Vitest (A Régua)
O Vitest roda em milissegundos sem abrir navegadores, atacando funções isoladas.
- O Alvo: Funções matemáticas invisíveis, cálculos complexos, e regras de Segurança de Linha (RLS) testadas via banco de dados local do Supabase.
[!IMPORTANT] Resumo Arquitetural para Desenvolvedores: A sua prioridade em QA é blindar as rotas críticas. Utilize Playwright para E2E integrado na Vercel (CI/CD) validando fluxos inteiros pós-desenvolvimento, e utilize Vitest com TDD para funções puras do backend. Evite BDD e não persiga métricas de cobertura inatingíveis em detrimento da velocidade de entrega.
Para escalar o desenvolvimento mantendo a segurança dos dados dos seus clientes, a fundação exige isolamento total de ambientes. Siga obrigatoriamente para o próximo capítulo: Múltiplas Contas: Supabase & Vercel CLI (Isolamento de Tokens).