1541 z moich
1624 testów gry
nigdy nie uruchamia gry.

Każdy tutorial o testowaniu w Unity pokazuje, jak napisać test. Prawie żaden nie mówi, dlaczego twoja gra będzie się przy tym opierać — a ta część to architektura, nie narzędzia.

Oto kształt zestawu, który się nie opierał, zmierzony, a nie zapamiętany:

Dziewięćdziesiąt pięć procent z nich działa bez sceny, bez MonoBehaviour i bez klatki. Ta proporcja nie jest dyscypliną ani upodobaniem. Jest bezpośrednią konsekwencją jednej reguły, a ta reguła to cały ten artykuł.

Jeden obiekt może zmieniać stan. To jest ta reguła.

Tym, co czyni grę testowalną, nie jest framework, biblioteka do mocków ani wstrzykiwanie zależności. Jest nim to, że istnieje dokładnie jedno miejsce, w którym świat może się zmienić, i przechodzi przez nie wszystko: każdy przycisk, każdy tik, każdy system.

W moim projekcie ten obiekt nosi taki komentarz i jest to najbardziej nośny akapit w całej bazie kodu:

Przeczytaj twierdzenie przyczynowe w środku: i dlatego test może przegrać cztery lata. Testowalność nie jest funkcją, którą ktoś zbudował. Jest tym, co dostajesz za darmo, gdy nic nie może zmienić świata za plecami tej bramy.

Drugi akapit robi cichszą robotę. Ustalona, udokumentowana kolejność operacji oznacza, że test może sprawdzać stan po dowolnym dniu i dostawać tę samą odpowiedź za każdym razem — z tego samego powodu, dla którego kampania w ogóle jest powtarzalna, czyli z tematu artykułu o deterministycznym losowaniu. Kolejność i determinizm to ten sam problem w dwóch kapeluszach.

Pomiar, który mówi, czy to masz

Jest jednolinijkowy sprawdzian na to, czy twoja logika gry jest testowalna, i jest uczciwszy niż jakiekolwiek deklaracje. Policz, ile plików twojej symulacji importuje silnik:

U mnie odpowiedź brzmi 0, na 98 plikach. Nie dlatego, że importowanie silnika jest zakazane jakąś regułą, którą egzekwuję, tylko dlatego, że gdy symulacja operuje na własnym stanie wyłącznie przez jedną bramę, nigdy nie ma powodu sięgać po Vector3, Debug.Log czy Time.deltaTime. Silnik okazuje się rzeczą, której logika nigdy nie potrzebowała.

Jeśli twoja liczba jest duża, to właśnie jest ta robota. Każde using UnityEngine w pliku z regułami to mały zakład o to, że ta reguła zawsze będzie działać wewnątrz gry — i to ten zakład sprawia później, że czteroletniej kampanii nie da się przetestować w sekundę.

Assembly definitions to część, która tego pilnuje

Reguła, której nikt nie złamie przez przypadek, jest warta więcej niż reguła, z którą wszyscy się zgadzają. Assembly definitions są sposobem, w jaki Unity ci to daje, i są krokiem pomijanym przez większość tutoriali, bo przykład-zabawka ich nie potrzebuje.

W moim projekcie robią to cztery pliki:

Plik asmdef testów wart jest przeczytania linijka po linijce, bo trzy jego pola to te, które ludzie ustawiają źle:

• "includePlatforms": ["Editor"] to jest to, co w ogóle czyni z nich testy Edit Mode. Dokumentacja Unity mówi, że assembly testowe celujące wyłącznie w Editor jest domyślnie traktowane jako Edit Mode.
• "defineConstraints": ["UNITY_INCLUDE_TESTS"] trzyma całe assembly poza buildem gracza. Bez tego możesz wysłać graczom swój kod testowy.
• "autoReferenced": false sprawia, że nic nie może przypadkiem zależeć od twoich testów. Powinno być prawdą w każdym assembly testowym i prawie nigdy nie jest.

Cichą korzyścią jest lista referencji. Ponieważ assembly testowe deklaruje dokładnie, co widzi, błąd architektoniczny — na przykład plik symulacji sięgający do interfejsu — przestaje być kwestią code review, a staje się błędem kompilacji.

Do czego służą pozostałe osiemdziesiąt trzy testy

Artykuł byłby schludniejszy, gdyby odpowiedź brzmiała „do niczego, wrzuć wszystko do Edit Mode". Jest błędna, a te osiemdziesiąt trzy to miejsce, gdzie mieszka konkretna klasa błędów.

Testy Play Mode mają pokrywać wszystko, czego tematem jest silnik: ładowanie scen, podpięcie prefabów, interfejs istniejący dopiero po wyrenderowaniu dokumentu, korutyny, fizykę. Ale kategoria, którą ludzie pomijają, jest tą ważną — testy dowodzące, że rdzeń bez sceny jest faktycznie podłączony do tego, co widzi gracz.

Czym się te 1541 testów okazało

„Tysiąc sześćset testów" brzmi jak liczba zaprojektowana, żeby robić wrażenie, i sama w sobie by nią była. Pożyteczniej rozbić ją na cztery zadania, które wykonują, bo czwarte ma prawie nikt:

Warstwę spójności dodałbym w cudzym projekcie jako pierwszą. Test, który przechodzi twoją zawartość i sprawdza, że jest poprawnie zbudowana, kosztuje godzinę i nigdy nie przestaje się zwracać, bo to w zawartości solowy twórca robi najwięcej pomyłek i ma najmniej kontroli.

Ile to kosztuje i kiedy się nie opłaca

Pisałbym reklamę, a nie poradnik, gdybym skończył w tym miejscu.

Prawdziwym kosztem nie jest pisanie testów. Jest nim to, że architekturę trzeba ustalić wcześnie, a jej dorobienie później jest drogie. Oddzielenie symulacji od silnika po fakcie oznacza znalezienie każdego miejsca, gdzie reguła czyta Time.deltaTime albo zahacza o MonoBehaviour, a w projekcie dowolnej wielkości to tygodnie, nie popołudnie. Opisałem jedyny raz, kiedy musiałem to zrobić, i nie było przyjemnie.

Drugim kosztem jest to, że rdzeń bez sceny jest trochę mniej wygodnym sposobem pisania gry. Nie przeciągniesz wartości na komponent w inspektorze tak, żeby symulacja ją zobaczyła. Wszystko jest jawne, co jest lepsze w dwunastym miesiącu i oznacza więcej pisania w pierwszym tygodniu.

Kolejność, w której zrobiłbym to ponownie

• Umieść reguły tam, gdzie nie ma silnika. Jeden folder, zero using UnityEngine, zweryfikowane grepem powyżej. Wszystko inne z tego wynika i nic bez tego nie działa.
• Uczyń jeden obiekt jedyną drogą do zmiany stanu. Akcje gracza i tik przechodzą przez niego, w udokumentowanej kolejności.
• Dodaj cztery assembly definitions, żeby granica była błędem kompilacji, a nie nawykiem.
• Napisz testy spójności na zawartości zanim napiszesz testy reguł. Najtańszy współczynnik trafień w całym zestawie.
• Dodaj trzy testy podłączenia w Play Mode, żeby zielony zestaw nie mógł współistnieć z pustym ekranem.

Pytania, które ludzie zadają