Blog / Wskazówki
Testowanie systemów Blueprint przed wydaniem
Systemy Blueprint łatwo zepsuć, nawet tego nie zauważając: zmieniona nazwa zmiennej, zmieniony struct, odwołanie do innego folderu, które działa na twoim komputerze, a zawodzi u kupującego. Każde wydanie Rookspire przed publikacją przechodzi przez tę samą bramkę.
Co uruchamia bramka
- Pełna przebudowa każdego Blueprintu z jego skryptu, więc nic nie zależy od ręcznej edycji.
- Kompilacja z zerową liczbą błędów i ostrzeżeń.
- Kontrola odwołań, która odrzuca każdy asset wskazujący poza własny folder produktu. To dzięki niej każdy system da się zainstalować osobno.
- Każda mapa uruchamiana przez 30 sekund z zerową liczbą komunikatów runtime w logu.
- Testy funkcjonalne w Play In Editor, po jednym na każde istotne zachowanie.
Test, który nigdy nie zawiódł, niczego nie dowodzi
Nowy test jest pisany tak, by najpierw nie przechodził: zachowanie zostaje celowo zepsute, test musi zmienić się na czerwony, a potem poprawka zmienia go na zielony. Test, który zawsze tylko przechodził, może w ogóle niczego nie testować.
I na końcu człowiek
Niektóre rzeczy zobaczy tylko człowiek: czy przeciąganie jest wygodne, czy podpowiedź jest czytelna na tle jasnego nieba. Każde wydanie jest też ręcznie sprawdzane na swojej mapie demo.