D'après mon expérience, ce n'est pas très courant.
La plupart du temps, les tests unitaires ne se produisent pas car la plupart des développeurs de jeux sont issus d'une époque et d'une culture antérieures à la généralisation de ce type. Il est donc difficile de soutenir que de telles méthodes sont nécessaires. Cela est devenu encore plus vrai au cours des dernières années, l’espoir étant que l’utilisateur soit en mesure de corriger son propre logiciel après sa publication.
C'est en partie parce que le langage dominant dans l'industrie du développement de jeux est le C ++, ce qui rend les tests unitaires un peu plus lourds que d'autres langages. Les frameworks de tests unitaires existent, mais ils ne sont pas aussi faciles à utiliser que des systèmes similaires dans des langages plus modernes qui peuvent utiliser la réflexion et des astuces similaires pour accélérer la détection des cas de test.
En outre, c’est parce que les jeux ne se prêtent généralement pas aux tests unitaires - une grande partie de la logique dépend de sources semi-déterministes (matériel graphique, cadencements d’entrée, fréquence de trame, par exemple); graphiques à l’écran, effets sonores) et certains n’ont presque aucune signification en dehors du contexte de jeu complet (par exemple, IA réactive complexe, simulations physiques). Il existe des exceptions - beaucoup, si vous travaillez dur pour créer le code de cette façon - mais dans l'ensemble, les tests coûtent plus cher dans les jeux que dans la plupart des autres types de logiciels et le rapport coût / bénéfice est donc plus discutable.
En ce qui concerne les tests d'intégration, je n'ai jamais entendu parler de ce terme explicitement utilisé dans le développement de jeux, mais de nombreux développeurs effectuent des tests automatisés de l'ensemble du système, dans la mesure du possible. En un sens, je dirais peut-être qu'un développeur professionnel sur trois le fait, car il n'est pas toujours facile à configurer et parce que les avantages sont réduits du fait que pratiquement tous les développeurs de moyenne à grande taille (ou leur éditeur) ont une assurance qualité. département qui effectuera manuellement des tests similaires. L’assurance-qualité est généralement beaucoup moins payée que les développeurs; il peut donc être considéré comme économique de leur laisser les tests, plutôt que d’y investir du temps de code supplémentaire. (Controversé.)