Integration Testing É a Parte Que a AI Não Pode Pular Por Você

A plataforma funciona. End-to-end, todo o caminho: log in, navegar pelo lobby, sentar em uma mesa, ver os assentos, abrir o diálogo de buy-in, observar uma mão.

Chegar aqui levou quatro posts. Um bug de routing, um mismatch de formato de dados, um auth guard quebrado, um ambiente de desenvolvimento que estava silenciosamente ignorando mudanças de código.

Também levou integration testing. Que é sobre o que este post fala.

Como a Fase de Testing Pareceu

Testamos usando Playwright -- uma ferramenta de automação de browser que escreve scripts de interações reais de browser e verifica os resultados. Browser real. Requests reais. UI renderizada real.

A sessão: log in com credenciais de teste, chegar ao lobby, confirmar que as cards da mesa renderizam na altura correta, navegar para uma mesa, confirmar que a barra de header aparece com um botão de lobby e botão de help, confirmar que o seat picker renderiza todos os assentos abertos.

Cada passo falhou na primeira execução.

As cards da mesa mediam 572 pixels de altura porque CSS Grid aplica align-items: stretch por padrão quando há apenas um item na linha. Ninguém especificou isso. Ninguém quebrou intencionalmente. É só o que CSS faz.

Navegar para uma mesa enviava o browser para um loop de redirect. O auth guard estava checando um valor de contexto do router que nunca era populado.

Esses não são modos de falha específicos de AI. É a classe de bugs que só aparecem quando o stack completo roda junto. Apareceriam também em código escrito por humanos. A fase de testing pega elas de qualquer jeito.

Por Que Código Gerado por AI Ainda Precisa Disso

Existe uma versão de desenvolvimento assistido por AI que trata testing como opcional. O raciocínio: o spec está correto, o agente implementa o spec, portanto a implementação está correta.

Esse raciocínio falha na camada de integração.

Componentes individuais podem cada um implementar seu spec corretamente e ainda assim falhar em se comunicar entre si. O spec descreve comportamento em isolamento. Integration testing verifica comportamento em composição. Uma especificação de 100 páginas que cobre cada domínio do sistema ainda não descreve cada default de CSS Grid e cada ordem de inicialização de context do router.

Rodar a coisa é a única forma de ver como rodar a coisa parece.

O Que o Humano Ainda Faz

Cada falha na sessão de testing foi identificada por uma pessoa observando um browser. A card do lobby esticava para altura completa -- essa observação é visual, não logada. A mesa carregava em branco -- isso exigia observar os network requests e notar o 404. O loop de redirect foi rastreado seguindo o histórico de navegação do browser.

Essas observações acontecem antes da AI se envolver no diagnóstico. O agente pode rastrear um bug que você descreveu. A descrição exige um humano que entende como o comportamento é supposed to look.

Isso não é uma limitação da metodologia. É a metodologia funcionando corretamente. O humano define o sistema, verifica o output, e escala falhas. O agente diagnostica e arruma. Essa divisão se sustenta por toda a fase de testing.

Onde Estamos Agora

O ambiente de dev passa end-to-end testing. A plataforma está operacionalmente pronta. Entre agora e o beta aberto: validação final em staging, a integração do card payment processor, e enforcement de geofencing.

A fase de testing não acabou. Subiu no stack.

O salty.poker changelog é atualizado à medida que enviamos. Siga se quiser rastrear o build em tempo real.

Para a série completa sobre a metodologia de engenharia -- como o spec dirige as sessões, como o papel do arquiteto se vê através da fase de testing, e o que quase 30 anos construindo software te ensinam sobre iteração -- essa série corre em paralelo em The Salty Korean.

Stay salty.