createByTemplate(), getAction() — это в терминах Battle (в рамках domain language) что такое?

в целом все отлично может ыть и модуль удобен (я не сомтрел), честно может быть удобен

но ДДД заявлено, а по ДДД ничего не работает, тк нет языка работы с ним, есть общий язык "с объектами", добавь команду, дай результат, зарегать персонажа

маловато для боя

бой это:
- сразиться двум/трем/N
- получить победителя/проигрвышего
- остановить бой
- получить результат боя
- напасть
- вывести из боя
- сбежать
- ввести в бой нового юнита
- перемириться
- получить состояние сражающихся (а не "юнит да свое. состояние")


это уже намек на ДДД (как и говорил, Use cases)
ну и получать результаты все событиями — было бы отлично

Хотя опять таки, выглядит чистенько как по мне, зависимостей особо не видно...

ну я могу сказать так - это не изолированные тесты)

я тоже когда-то билдеры и фабрики в юнит тестах делал что бы "спрятать" проблемы о которых выше писал) тоже чистенько выглядит и даже тестит чего-то.

Я повторюсь - я не говорю что все плохо. я говорю что есть куда смотреть и разбираться

Из-за чего, из-за фабрики ?

- сразиться двум/трем/N - пожалуйста, сколько данных по юнитам передано - столько и будут сражаться
- получить победителя/проигрвышего - Result->getWinner()
- получить результат боя - Result и все что в поддиректориях

Нет, потому что не предусмотрено бизнес-логикой:
- остановить бой
- напасть (то, что бой происходит - подразумевает нападение одной из сторон на другую)
- вывести из боя
- сбежать

но в целом меня задевает фраза про "заебись архитектура а не эти ваши что бы фичи быстрее" - заебись архитектура это когда фичи быстрее. А "фичи быстрее и не делать архитектуру" обычно медленно выходит)

ну в целом где там изоляция тест кейсов?

я вот могу сломать реализацию какого-нибудь там unit и это сломает почти все тесты)

фабрики в тестах сделаны для удобства написания тестов, чтобы те же юниты или команды создавать одной строчкой

Эм... ну если этот юнит участвует в кейсах, то да, а что в этом такого? Везде его мокать:?

https://blog.thecodewhisperer.com/series#integrated-tests-are-a-scam - тут же идея какая - "тотальная изоляция и контрактные тесты" -> это очень неудобно делать когда высокая связанность -> более высокое давление на дизайн модулей -> уменьшение количества зависимостей и сайд эффектов -> event driven + whole value...\

а разве тесты не для этого созданы? чтобы показывать, что логика сломалась

вот если код сломан, а тесты проходят - вот это проблема

Это камень в огород dummy классов и их переиспользованию в тестах.
Почему мок стабильнее, чем dummy?

dummy это вообще заглушка с которой ты не взаимодействуешь. ты про fake. а тут реальная имплементация

Реальная имплементация плохо?

Читал иное мнение

ну я пример, надо смотреть как используется...
я нашел много get, add, мало юзкейсов, мог просто не увидеть...