Mais de 1000 testes para um jogo de hobby — desperdício?

Nosso projeto já tem bem mais de mil testes automatizados: cerca de 990 no lado do servidor, uns 120 no cliente Unity. Para um projeto de família, isso parece exagero. É o contrário — e eis o porquê.

Os testes são nosso segundo desenvolvedor. Num projeto solo, não há ninguém para dizer na revisão de código: “Peraí, isso quebra a criação de itens.” Os testes são esse colega. Cada mecânica do jogo — receitas, oxigênio, fome, comportamento das criaturas, senhas de mundo — tem testes que rodam a cada mudança. Refatorar sem medo é o ganho de verdade.

Rápidos o bastante para não irritar. Testes que levam um quarto de hora ninguém roda. Por isso o nosso gate de CI tem dois estágios: a verificação do pull request roda em uns bons três minutos com os testes rápidos; a suíte completa, lenta, roda depois. Assim o ciclo de desenvolvimento continua ágil sem perder cobertura.

Testar o Unity é um assunto à parte. A lógica do cliente é difícil de testar dentro de um motor em execução. Nosso truque: a lógica central do cliente vive numa biblioteca própria que roda sem o Unity — testamos isso sem interface, como código normal. Só o que realmente precisa do motor roda como teste EditMode/PlayMode.

Avisos são erros. Nossa CI compila com “warnaserror”: todo aviso do compilador quebra a build. Parece pedante, mas evita o cemitério de avisos em que o único aviso importante acaba afogado.

O balanço honesto: escrever testes custa talvez um quinto do tempo de desenvolvimento. Mas todo recurso corrigido continua corrigido — e, para um projeto que ganha vida nas noites depois do trabalho, nada é mais valioso que a certeza de que o recurso do fim de semana não destruiu o da terça-feira.