Вопрос по структура проекта (модули main, test и api)

Версия Minecraft
1.7.10
1,159
38
544
Доброго всем дня. Как мы все знаем, создание мода начинается со скачивания MDK (или src для старых версий), его распаковки, импорта в IDE и запуска градл-тасков. Я заметил, что скачанный MDK с самого начала имеет 3 модуля:
  • <MOD_NAME>_main
  • <MOD_NAME>_test
  • <MOD_NAME>_api
Интуиция подсказывает мне, что в main мы храним весь код нашего мода, в api - классы и методы, которые могут быть использованы в других модах, зависимых от нашего, а в test - юнит-тесты и инструментальные тесты
Это определение из Android-разработки. Бывают локальные юнит-тесты (которые не требуют запуска игры, т.к. тестируемый код не использует классы майна) и инструментальные тесты (это юнит-тесты, в которых тестируемый код зависит от классов майна). Инструментальные тесты используются, когда ванильные классы нельзя замокать. Локальные тесты же просто запускают JVM и выполняются, как простейший helloworld.

И main, и test модули имеют прописанный путь к классу, который позволяет запустить майн из IDE с последующим билдом и инжектом нашего мода (в 1.12.2 test не имеет это ссылку)
XML:
<CLASSES>
  <root url="file://$USER_HOME$/.gradle/caches/minecraft/net/minecraftforge/forge/1.7.10-10.13.4.1558-1.7.10/start" />
</CLASSES>

Я подумал, что будет здорово хранить инструментальные тесты в test модуле и при запуске игры просто указывать его в параметре "Use classpath or module":
2018-07-11_12-42-23.png

ВНИМАНИЕ, ВОПРОС!
Вопрос в том, как это сделать? Как прописать тест, который будет запускаться в самой игре?

ВАЖНОЕ P.S.
Очень вероятно, что я имеют неправильное представление зачем нужны эти модули в проекте и не знаю как их использовать. Любые наставления категорически приветствуются
 
344
1
47
Такого нет. Если тебе нужно работать с GUI и настраивать что-то простое, то используй дебаг. Он позволяет без перезапуска изменять и настраивать интерфейс.
 
1,159
38
544
Если тебе нужно работать с GUI и настраивать что-то простое, то используй дебаг. Он позволяет без перезапуска изменять и настраивать интерфейс.
Мне не гуи нужно тестить, а контейнер для него. Да К тому же хочется как-то защищаться от регрессии
 
344
1
47
Контейнер тоже можно. Я настраивал почти все так, включая кастомный инвентарь.

Но им нельзя делать большие изменения, иначе перезапуск
 
1,159
38
544
1,111
47
420
Как много умных слов на один квадратный пост о_О.
По моему лчному опыту и мнению запускать майн ради тестов крайне не удобно. Я как то делал провода, а к ним соответственно прилагается поиск всех соседей и поиск кратчайшего пути и прочее такое. Там я писал очень много тестов. Этот пример и будем использовать.
Как я поразмыслил вместо того чтобы фигачить в майн куда проще и удобней будет создать тестовую среду ок да. Что нужно поиску соседей? Ему нужен доступ к миру. Окей вообще без проблем накатываем интерфейс для доступа к миру. Благо блоки не нуждаются в инициализации майна.
Вообще на любой случай обращения к майну у меня была своя абстрактная прослойка у которой было две реализации: тестовая и майновская. В этом плане писать реально годные тесты для майна жесточайший батхерт, но ты сам захотел.
 
344
1
47
Жестоко конечно, о таком я еще не задумывался. Но вещь реально годная если судить из твоих слов. Глобальные вещи так просто не протестишь... А если мир будет сам по себе запускаться, то это сократит в несколько раз. А если еще перегрузчик сделать или что-то в том роде, то да. Но вот сколько времени на данное истратить - уже другое дело.
 
1,159
38
544
Подумал немного и написал команду к майну, которая просто передает такие такие параметры как World и EntityPlayer (не замоканные) в уже готовые юнит тесты. Все работает, расходимся.

жесточайший батхерт
Уже на своей шкуре испытал. Таки да, сложные вещи действительно тяжко тестить, но по большому счету, большая часть успешно покрывается тестами.
 
1,111
47
420
Подумал немного и написал команду к майну, которая просто передает такие такие параметры как World и EntityPlayer (не замоканные) в уже готовые юнит тесты. Все работает, расходимся.
:cautious:
Тесты предполагают нажатие по кнопачке и прохождение тестов одного за другим по средствам Gradle. Удобно знаете ли тесты всовывать в пайплайн сборки чтобы уж наверняка. То что сделал ты не сильно знаете ли отличается от тестов по средствам дебага)0 Имхохо мне не нравится такой подход
 
1,159
38
544
прохождение тестов одного за другим по средствам Gradle
Да я так и делаю. И таск написал, чтобы все тесты срабатывали перед каждым раном игры.


То что сделал ты не сильно знаете ли отличается от тестов по средствам дебага
А юнит тесты разве вообще отличаются от тестов по средствам дебага? Только в одном случае ты сам сверяешь значения переменных в отладчике, а в другом - это делает тест.

Имхохо мне не нравится такой подход
А сам бы как сделал?
 
1,111
47
420
Я делал так чтобы в IDE я мог тыкнуть на папочку тестов и жмакнуть Run All Tests
Да я так и делаю. И таск написал, чтобы все тесты срабатывали перед каждым раном игры.
Поделись своей мудростью как это сделать не запуская майн и не накручивая интерфейсы?
 
1,159
38
544
1,159
38
544
Разбираясь как сделать апи к моду и как юзать сторонние апи, я выяснил кое-что интересное касательно модуля api:
У меня есть подозрение, что api-модуль мода служит не местом куда ВАМ нужно поместить api для вашего мода, а местом, куда помещается исходники СТОРОННЕГО АПИ, который ВЫ(!) хотите использовать. Это подтверждает тот факт, что при билде мода код из api-модуля НЕ ПОПАДАЕТ в jar'ник. Скорее всего это осталось с тех темных времен, когда не было градла, или когда апи было удобнее распространять архивом с кодом, а не скомпилированным бинарником.

Т.е. задача api-модуля - предоставить классы апи в рантайме, но не включить их в билд. Я нахожу это очень странным. Сейчас же большинство апи поставляется в виде скомпилированных бинарников, которые подключаются к игре при помощи механизма зависимостей градла. Т.е. api-модуль стал не нужен. Вернее, остался "на всякий случай". Наверное на тот, если автор лох и не осилил создать maven-реп :D Ну или для версий, для которых ForgeGradle'а нет.

Я-то думал что нужно помещать туда апи для своего мода. Даже градл-таск написал, чтобы из api-модуля билдился отдельный бинарник. А оказывается, чтобы сделать апи для мода порядочным способом (Т.е. способом, которые запилили авторы Forge) - нужно в main-модуле создать пакет, в котором будете храниться апи нашего мода, создать в нем package-info.java и в этом созданном файле заюзать аннотацию @API. Стоит иметь ввиду, что данная аннотация юзается НА ИМЯ ПАКЕТА, а не на класс/метод/поле как вы могли подумать. Это значит что вам в package-info.java вообще не нужно ничего писать. Объяснение для тех, кто не знает что такое package-info.java :3 Пример:
Код:
@API(owner = "weightapi", provides = "WeightAPI", apiVersion = "1.0.0")
package ru.rarescrap;

import cpw.mods.fml.common.API;

А что дальше? А хз, я еще разбираюсь. Некоторые кусочки инфы, озвученные выше, нашел тут.
 
1,159
38
544
1,159
38
544
Неужели вы так часто это делаете?)
К сожалению. Иногда бывают моменты, когда часто меняю структуру класса. И даже если среда пишет, что она успешно релоаднула класс, это может оказаться совсем не так :D. Так что приходится часто его перезапускать
 
Сверху