Z mojego doświadczenia nie wynika to zbyt często.
Przeważnie testy jednostkowe nie są przeprowadzane, ponieważ większość twórców gier wywodzi się z przeszłości i kultury, zanim takie rzeczy były szeroko rozpowszechnione, dlatego trudno jest teraz argumentować, że takie metody są konieczne. Stało się to jeszcze bardziej prawdziwe w ostatnich latach w oczekiwaniu, że użytkownik będzie mógł łatać własne oprogramowanie po wydaniu.
Częściowo dzieje się tak dlatego, że dominującym językiem w branży tworzenia gier jest C ++, co sprawia, że testowanie jednostek jest nieco bardziej skomplikowane niż w przypadku innych języków. Struktury testów jednostkowych istnieją, ale nie są tak łatwe w użyciu, jak podobne systemy w bardziej nowoczesnych językach, które mogą używać refleksji i podobnych sztuczek, aby przyspieszyć wykrywanie przypadków testowych.
Również dlatego, że gry zazwyczaj nie poddają się testom jednostkowym - duża część logiki zależy od źródeł pół-deterministycznych (np. Sprzęt graficzny, czasy wejściowe, częstotliwość klatek), duża część wyników jest trudna do zmierzenia (np. grafika na ekranie, efekty dźwiękowe), a niektóre są prawie bez znaczenia poza pełnym tworzeniem kontekstu gry (np. złożona reaktywna AI, symulacje fizyki). Są wyjątki - wiele, jeśli ciężko pracujesz, aby kod był w ten sposób - ale ogólnie testowanie jest droższe w grach niż w większości innych rodzajów oprogramowania, więc stosunek kosztów do korzyści jest bardziej wątpliwy.
Jeśli chodzi o testy integracyjne, nigdy nie słyszałem o tym, aby termin ten był wyraźnie używany w rozwoju gier, ale wielu programistów przeprowadza automatyczne testy całego systemu, jeśli to możliwe. Domyślam się, że może 1 na 3 programistów robi to, ponieważ nie zawsze jest to łatwe do skonfigurowania i ponieważ korzyści są zmniejszone przez fakt, że prawie każdy średni lub duży programista (lub ich wydawca) ma kontrolę jakości dział, który ręcznie wykona podobne testy. Za kontrolę jakości zazwyczaj płaci się znacznie mniej niż programistów, dlatego może być uważane za ekonomiczne pozostawienie testowania, zamiast inwestowania dodatkowego czasu na kod. (Kontrowersyjny.)