Обычно разработчик проверяет плагин руками: собрал jar, закинул на тестовый сервер, зашёл в игру, ввёл команду, посмотрел. Это работает, пока плагин маленький. Когда в нём десятки команд и механик, проверить всё после каждого изменения руками уже невозможно, и ошибки начинают проскакивать в релиз. Автотесты решают эту проблему: код проверяет код. Разберёмся, как это работает для плагинов и зачем нужен MockBukkit.
Что такое автотесты
Автотест - это небольшая программа, которая вызывает часть вашего кода и проверяет результат. Например: «если у игрока 100 монет и он покупает предмет за 30, у него должно остаться 70». Тест запускается за доли секунды и сразу говорит, работает код или нет.
Главная ценность тестов не в том, что они находят ошибки в новом коде, а в том, что они ловят ошибки в старом. Вы поменяли одну функцию, а сломалась другая, о которой вы даже не думали. Без тестов это всплывёт у игроков. С тестами вы увидите красную строку ещё до сборки.
Проблема плагинов и решение MockBukkit
Плагин сложно тестировать обычными способами: почти весь его код зависит от сервера - игроков, миров, инвентарей. Запускать настоящий сервер для каждого теста долго и неудобно.
MockBukkit - это «поддельный» сервер, который работает прямо внутри тестов. Он имитирует основные части Bukkit и Paper: можно создать тестовый мир, добавить игроков, выдать им предметы, вызвать команду, запустить событие - и проверить, что ваш плагин отреагировал правильно. Всё это за доли секунды и без Minecraft.
Как это выглядит
Тесты подключаются в тот же проект Gradle, что и плагин. Перед каждым тестом MockBukkit запускает свой сервер и загружает ваш плагин. В самом тесте вы описываете ситуацию и ожидание.
Например, тест команды: создаём игрока с правом на команду, выполняем команду от его имени и проверяем, что ему пришло нужное сообщение и выдан предмет. Второй тест: игрок без права выполняет ту же команду и должен получить отказ. Третий: команда без аргументов показывает подсказку. Каждый тест проверяет одну ситуацию, и вместе они описывают, как должна работать команда.
Что тестировать в первую очередь
Не нужно пытаться покрыть тестами весь плагин сразу. Начните с того, где ошибка стоит дороже всего.
Экономика и всё, что связано с деньгами: покупки, продажи, награды, комиссии. Ошибка здесь - это дюп денег или потерянные покупки.
Логика, которая принимает решения: кому что положено, сколько стоит, сработал ли кулдаун. Такие функции легко тестировать, и ошибки в них самые незаметные.
Разбор конфигов и аргументов команд: что будет, если в конфиге опечатка, а игрок ввёл буквы вместо числа.
Отдельно стоит писать тест на каждую найденную ошибку. Нашли баг - сначала напишите тест, который его воспроизводит, потом исправьте код. Тогда эта ошибка уже никогда не вернётся незаметно.
Делайте код удобным для тестов
Лучше всего тестируется логика, которая не зависит от сервера напрямую. Если расчёт цены спрятан внутри обработчика события, его трудно проверить. Если он вынесен в отдельный класс, который принимает числа и возвращает число, его можно протестировать даже без MockBukkit.
Хорошее правило: обработчики команд и событий должны быть тонкими. Они собирают данные из игры и передают их в отдельные классы с логикой. Тогда большая часть кода тестируется просто и быстро, а MockBukkit нужен только для проверки связки с игрой.
Чего тесты не заменят
MockBukkit имитирует сервер, но не полностью. Сложные вещи вроде генерации мира, физики, некоторых пакетов и поведения конкретного клиента в нём либо упрощены, либо отсутствуют. Поэтому автотесты не заменяют проверку на настоящем тестовом сервере перед релизом. Они избавляют от рутинной проверки основы, а живая проверка нужна для того, что тесты охватить не могут.
Тесты в сборке
Самое удобное - запускать тесты автоматически при каждой сборке. Gradle делает это по умолчанию: если хоть один тест падает, jar не собирается. Если код хранится на GitHub или GitLab, можно настроить запуск тестов при каждом изменении - тогда вы сразу видите, какое изменение что-то сломало.
Пример
Разработчик плагина аукциона после каждого обновления получал жалобы: то не работала комиссия, то пропадали лоты при отмене. Он написал два десятка тестов на MockBukkit: продажа, покупка, отмена, комиссия, нехватка денег, одновременная покупка двумя игроками. Первый же запуск нашёл старую ошибку с округлением комиссии. Следующие обновления выходили без жалоб на сломанную базовую логику.
Как начать, если тестов пока нет
Не пытайтесь за один раз написать тесты на весь существующий плагин. Выберите одну самую важную функцию, например покупку в магазине, и напишите на неё три-четыре теста: обычная покупка, нехватка денег, покупка без прав, некорректное количество. Это займёт вечер, но сразу покажет, как устроены тесты в вашем проекте.
Дальше добавляйте тесты постепенно: на каждую новую функцию и на каждую найденную ошибку. Через пару месяцев окажется, что самые важные части плагина покрыты, и обновления перестали пугать. А новый разработчик в команде по тестам быстро поймёт, как должен работать код.
Наш взгляд
Автотесты кажутся лишней работой, пока плагин маленький, и становятся спасением, когда он вырастает. Начните с тестов на деньги и важную логику, пишите тест на каждую найденную ошибку и держите обработчики тонкими. MockBukkit делает это реальным даже для кода, который плотно связан с игрой.
Пишете тесты для своих плагинов или проверяете всё руками?
