Tout d'abord, vous auriez besoin d'un cadre de tests unitaires. Dans le passé, j'ai utilisé UnitTest ++ et Google Test . Le premier est très léger et le second est plus en vedette mais un peu plus encombrant. Il s'intègre bien avec Google Mock si vous avez besoin de ce genre de chose. Il y a bien sûr de nombreuses autres options: voir cette liste (par l'auteur éventuel de UnitTest ++) et Wikipedia par exemple.
Les tests unitaires consistent à écrire des tests ciblés pour souligner des bits de code indépendants ("unités") particuliers isolés dans divers scénarios. Bien que dans certains cas, vous puissiez tout tester unitaire, il n'est généralement pas pratique d'atteindre une couverture à 100% et, en particulier dans les jeux, peut être assez difficile - on peut se demander si le test unitaire de votre sortie de rendu est significatif, utile ou un "vrai" test unitaire malgré tout.
Il est important de se rappeler que tout test (automatisé) est préférable à aucun test (automatisé). Vous ne devriez donc pas trop insister sur le fait que vos tests ne sont pas de "vrais tests unitaires" et être fier que vous ayez simplement des tests. Les cadres de tests unitaires sont généralement utiles pour créer des tests plus lâches et "non unitaires", car ils incluent des fonctionnalités permettant de regrouper les tests et de signaler les défaillances de manière uniforme.
Je vous encourage à ressusciter vos anciens tests et à les intégrer dans un projet de test en utilisant l'un des cadres disponibles - quelque chose que vous pouvez facilement exécuter de temps en temps (ou automatiquement dans le cadre d'une version ou d'une build d'intégration) qui exécute tous vos tests. Écrivez de nouveaux tests pour les bits de code car il devient évident qu'ils vous seraient utiles, par exemple si vous découvrez un bug subtil que vous auriez pu détecter avec un test, vous pouvez en ajouter un pour attraper toutes les régressions que vous pourriez faire à l'avenir.
Vous constaterez probablement que c'est principalement votre code utilitaire de niveau inférieur qui se prête aux tests unitaires, dans les jeux. C'est bien - c'est le code de base qui pourrait perturber beaucoup de couches supérieures s'il se casse.
Vous n'irez pas au purgatoire du programmeur pour ne pas avoir de tests pour chaque petite fonction et porte logique dans votre base de code, alors ne passez pas plus de temps que nécessaire pour écrire des tests. Si vous devez réfléchir plus longuement ou passer beaucoup plus de temps à rédiger les tests d'un module qu'il ne vous en a fallu pour créer le module, vous perdez peut-être votre temps. Les tests unitaires - les tests en général - sont un outil que vous apprenez à utiliser de manière appropriée pour vous aider, pas une corvée que vous devez effectuer pour tout.