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

  1. Pełna przebudowa każdego Blueprintu z jego skryptu, więc nic nie zależy od ręcznej edycji.
  2. Kompilacja z zerową liczbą błędów i ostrzeżeń.
  3. 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.
  4. Każda mapa uruchamiana przez 30 sekund z zerową liczbą komunikatów runtime w logu.
  5. 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.