Понад 1000 тестів для хобі-гри — марна трата?

У нашому проєкті тепер добре понад тисячу автоматизованих тестів: близько 990 на боці сервера, близько 120 у клієнті Unity. Для сімейного проєкту це звучить як надмір. Насправді навпаки — і ось чому.

Тести — наш другий розробник. У сольному проєкті нікому сказати під час код-рев'ю: «Стривай, це ламає крафт». Тести — це такий колега. Кожна ігрова механіка — рецепти, кисень, голод, поведінка істот, паролі світів — має тести, що запускаються після кожної зміни. Рефакторинг без страху — справжня перемога.

Досить швидкі, щоб не дратувати. Тести, що тривають чверть години, ніхто не запускає. Тому наш CI-шлюз двоетапний: перевірка pull request виконується трохи більше трьох хвилин зі швидкими тестами; повний повільний набір запускається потім. Так цикл розробки залишається жвавим без втрати покриття.

Тестувати Unity — окрема тема. Клієнтську логіку важко тестувати всередині запущеного рушія. Наш прийом: основна логіка клієнта живе в окремій бібліотеці, яка працює без Unity, — її ми тестуємо без графіки, як звичайний код. Лише те, що справді потребує рушія, запускається як тест EditMode/PlayMode.

Попередження — це помилки. Наш CI збирає з «warnaserror»: кожне попередження компілятора ламає збірку. Звучить педантично, але це запобігає кладовищу попереджень, у якому зрештою тоне те одне важливе.

Чесний підсумок: написання тестів коштує, можливо, п'яту частину часу розробки. Але кожна виправлена функція залишається виправленою — а для проєкту, що оживає вечорами після роботи, немає нічого цінніше за впевненість, що функція вихідних не зламала функцію вівторка.