Plus de 1000 tests pour un jeu amateur — du gaspillage ?

Notre projet compte maintenant bien plus d'un millier de tests automatisés : environ 990 côté serveur, à peu près 120 dans le client Unity. Pour un projet familial, ça ressemble à de l'excès. C'est tout le contraire — et voici pourquoi.

Les tests sont notre deuxième développeur. Dans un projet solo, personne n'est là pour dire en revue de code : « Attends, ça casse la fabrication. » Les tests sont ce collègue. Chaque mécanique de jeu — recettes, oxygène, faim, comportement des créatures, mots de passe des mondes — a des tests qui tournent à chaque modification. Pouvoir refactoriser sans peur, voilà le vrai gain.

Assez rapides pour ne pas agacer. Des tests qui durent un quart d'heure, personne ne les lance. C'est pourquoi notre contrôle CI se fait en deux étapes : la vérification de la pull request tourne en un peu plus de trois minutes avec les tests rapides ; la suite complète, plus lente, tourne ensuite. La boucle de développement reste ainsi rapide, sans perte de couverture.

Tester Unity, c'est un sujet à part. La logique du client se teste mal à l'intérieur d'un moteur en marche. Notre astuce : la logique centrale du client vit dans sa propre bibliothèque, qui tourne sans Unity — on la teste en headless, comme du code normal. Seul ce qui a vraiment besoin du moteur tourne en test EditMode/PlayMode.

Les avertissements sont des erreurs. Notre CI compile avec « warnaserror » : chaque avertissement du compilateur fait échouer le build. Ça a l'air pédant, mais ça évite le cimetière d'avertissements dans lequel le seul avertissement important finit par se noyer.

Le bilan honnête : écrire des tests coûte peut-être un cinquième du temps de développement. Mais chaque fonctionnalité corrigée reste corrigée — et pour un projet qui prend vie le soir après le travail, rien n'a plus de valeur que la certitude que la fonctionnalité du week-end n'a pas cassé celle du mardi.