не плохо ни хорошо - вопрос контрактов и взаимодействий. когда тебе неудобно подменять на фэйки везде то ВОЗМОЖНО что-то не то с контрактами (сложные)

Возможно я о них. Не вникал в разделение понятий.

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

еще вопрос стабильности - например у тебя может быть какой-то DateRange VO который пиздец стабильный (ибо че его менять) и тут можно не париться

ну мол не важно какой вид двойников ты юзаешь - тут юзается реальная имплементация. хорошо это или плохо - зависит от того что ты хочешь. Например если тебе важно протектировать взаимодействие с контрактом который ты НЕ контролируешь то тебе нужны интеграционные тесты и никаких тест даблов.

А что значит "протестированные классы без логики"?

get много там, где много свойств у объектов. Сейчас у Unit всего около 5 параметров влияющих на бой (хп, удар, скорость атаки, и т.д.), в полноценной реализации их будет около 30 - всякие там меткости, защита, блоки, шанс и сила крита, типы урона, сопротивления стихиям и т.д. - соответственно, чтобы получать эти параметры get-ров будет еще больше. Я не особо понимаю, как можно без этого - не публичными же свойства объектов делать

При этом понятное дело, что свойства будут группироваться - атакующие параметры будут вынесены в объект Damage, защитные - в Defence, но количество геттеров все равно никуда не денется

если мы говорим о тупых структурах данных без поведения то это структуры данных без поведения и там тест даблы не надо.

тест даблы нужны для изоляции, с тупыми структурами данных или там геттерами сеттерами нечего изолировать ибо это тупо data bag

Позже отпишу пример

классы без логики отлично закрывает какой-нибудь psalm 🙂

По поводу мало "юзкейсов" не понял, в тестах сейчас: Tests: 357, Assertions: 1266

И бизнес логика реализована пока процентов на 20%, соответственно их будет раз в 5 больше потом

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

я тоже против геттеров)

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

как вы получаете свойства объектов?

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

здесь мы возвращаемся к DDD - что там говорится - что объекты кода должны соответствовать объектам реального мира. Юнит в бою есть (одна боевая еденица) - есть, значит и объект должен быть

объекты реального мира это ты придумал, нет там такого

процессы реального мира - да может быть