Testes Automatizados na Prática com Unity Test Framework

Problema

Para manter o balanceamento adequado do jogo, era essencial garantir que todos os ScriptableObjects e todas as cenas de cada fase estivessem configurados corretamente, tanto nos valores quanto na existência adequada de GameObjects.

Se algum campo estivesse vazio ou alguma configuração estivesse incorreta, isso poderia quebrar o funcionamento de partes importantes do jogo.

Pensando nisso, criei uma bateria de testes automatizados para validar essas condições.

Identificação dos Casos de Teste

O primeiro passo foi identificar quais campos de ScriptableObjects e quais GameObjects eram fundamentais para o jogo funcionar corretamente.

Comecei listando casos como:

1. Cena: O campo “x” do GameObject ExemploConfig precisa estar vinculado ao ScriptableObject de mesmo nome da cena.

2. Cena: O número de GameObjects “y” precisa ser igual ao definido na configuração do ExemploConfig.

Esses foram apenas os casos iniciais. Durante o desenvolvimento, fui acrescentando novos testes sempre que percebia a necessidade.

Unity Test Framework

O Unity já vem integrado com o NUnit, permitindo escrever testes de forma estruturada.

Para quem nunca usou, recomendo o guia oficial da Unity: Como executar testes automatizados com o Unity Test Framework.

Existem duas categorias principais de testes:

• Edit Mode Tests: Executam no Unity Editor, sem iniciar o jogo. Ótimos para testar lógica pura, funções, cálculos e dados que não dependem do ciclo de vida do jogo.

• Play Mode Tests: Executam com o jogo rodando no Play Mode. Úteis para validar interações, comportamentos, MonoBehaviours, física e sistemas que precisam do loop de jogo ativo.

No meu caso, os Edit Mode Tests eram suficientes, já que eu precisava apenas validar dados de ScriptableObjects e verificar a existência de GameObjects em cenas.

Estrutura de Código

Organizei meus scripts de teste da seguinte forma:

• IndividualLevelTest: classe principal que contém os métodos [UnityTest] e a configuração inicial.

• LevelConfigTest: contém funções específicas para validar ScriptableObjects e seus campos obrigatórios.

• LevelSceneTest: segue a mesma lógica da anterior, mas validando a estrutura das cenas.

Testes Parametrizados

O Unity (via NUnit) permite passar parâmetros para funções de teste usando [ValueSource], criando testes orientados a dados.

Isso significa que consigo criar uma única função e rodá-la para todos os ScriptableObjects ou cenas, sem precisar escrever testes repetidos.

Dito isso comecei criando a função para pegar esses ScriptableObjects, essa função será passada como parâmetro [ValueSource]da função principal que irá executar os testes.

A vantagem disso é, cada vez que for criado um novo SO de LevelConfig, não preciso me preocupar em adicionar manualmente, pois assim que rodar o teste, já vai retornar todos que existem no projeto.

A partir disso então criei a função principal, passando como parâmetro minha função anterior e dentro dela chamei as funções que realmente faz a validação e o legal é que se falhar na primeira, já nem segue para as próximas e cada erro aparece individualmente.

Para validar a cena o processo foi o mesmo, criei uma função usada como [ValueSource] e a função que chama os testes, funciona igual, pega todas as cenas e valida o que está dentro dela.

Esse é um teste mais demorado e escala o tempo de execução de acordo com quantidade de cenas, pois é necessário abrir a cena e verificar, veja o código abaixo.

Conclusão

Criar testes automatizados para Unity usando Edit Mode e testes parametrizados me poupou horas de revisão manual e reduziu drasticamente erros de configuração.

Além disso, o uso de ValueSource permitiu que cada novo LevelConfig ou cena fosse automaticamente incluído nos testes, sem trabalho extra.

Hoje, sempre que crio algo novo no projeto, já penso no teste antes mesmo da implementação.

O resultado? Um desenvolvimento mais rápido, seguro e com muito menos dor de cabeça.

E confesso: agora estou viciada em criar testes automatizados. 😂