Comments 11
КДПВ на полтора метра — худший антипаттерн
Интересно было почитать — я подобное сам писал, когда нужно было POJO объект заполнить для проверки сериализации/десериализации. Заняло несколько десятков строк кода. А тут прямо серьёзная вещь, даже с поддержкой стратегий генерирования :)
Прочитал заголовок как «продам java объекты для Unit-тестирования». Прям таки объявление. Хорошее название — podam.
Использовать одну strategy для всех объектов — не очень удачное решение по-моему. На примере Country и City с парой полей, конечно, все будет хорошо, но если у вас будут объекты со сложными связями и генерировать надо псевдо-случайные связи — в этом strategy будет сущий ад из if-else.
Конечно, можно создать несколько factory, но можно ли связать объект из одной с объектами из другой (не руками)?
Или, например, в объект Country надо добавить только те City, которые проходят какое-то условие, это тоже решается через if-else?
Так же, по всей видимости, забыты enumeration'ы, которые живут в дб, их тоже руками в strategy добавлять?
В общем писали мы тоже такое дело, на первый взгляд похоже, что подам не делает за вас кучу работы, которую мог бы.
Конечно, можно создать несколько factory, но можно ли связать объект из одной с объектами из другой (не руками)?
Или, например, в объект Country надо добавить только те City, которые проходят какое-то условие, это тоже решается через if-else?
Так же, по всей видимости, забыты enumeration'ы, которые живут в дб, их тоже руками в strategy добавлять?
В общем писали мы тоже такое дело, на первый взгляд похоже, что подам не делает за вас кучу работы, которую мог бы.
Блин. Кто же говорит про одну стратегию для всех — это же просто пример использования. Просто инструмент — ООП в руки желающим, — выводите уровень абстракции стратегии на тот, который нужен. Наследуйте стратегии…
Создаём фабрики — не вижу проблемы связать фабрики друг с другом. Да, универсального способа разруливать сложную логику связей не существует, — но для каждой конкретной задачи, если подумать, существует элегантное решение.
Если речь идёт о справочниках, сделайте стратегию для отдельного атрибута, — в ней реализуйте обращение к базе, получение того, что нужно и возвращения генератору.
Это не библиотtка-пилюля-от-всех-проблем. Это альтернатива тому, чтобы сетить фикс значения в объекты и, по-возможности, организовать их генерацию.
Или, например, в объект Country надо добавить только те City, которые проходят какое-то условие, это тоже решается через if-else?
Создаём фабрики — не вижу проблемы связать фабрики друг с другом. Да, универсального способа разруливать сложную логику связей не существует, — но для каждой конкретной задачи, если подумать, существует элегантное решение.
Так же, по всей видимости, забыты enumeration'ы, которые живут в дб, их тоже руками в strategy добавлять?
Если речь идёт о справочниках, сделайте стратегию для отдельного атрибута, — в ней реализуйте обращение к базе, получение того, что нужно и возвращения генератору.
Это не библиотtка-пилюля-от-всех-проблем. Это альтернатива тому, чтобы сетить фикс значения в объекты и, по-возможности, организовать их генерацию.
Я только за генерацию. Просто похоже на инструмент, который делает inject значения в объект (может сгенерить рандом), а все остальное «сделай сам».
Или взять аннотации "@Podam...", это же жесть. Я понимаю, что не обязательно их использовать, но представьте это в domain model слое… Грубо нарушаем SRP, domain model зависит от тестовой dependency, domain model определяет поведение тестов.
Или взять аннотации "@Podam...", это же жесть. Я понимаю, что не обязательно их использовать, но представьте это в domain model слое… Грубо нарушаем SRP, domain model зависит от тестовой dependency, domain model определяет поведение тестов.
Он разбирает объект используя reflection, рекурсивно опускается до примитивов и коллекций. Аннотации — договорились — лучше не использовать. Если так уже надо работать с базой, можно это сделать на уровне своей абстракции.
public abstract class MyAbstractDataProviderStrategy implements DataProviderStrategy
Можно базу, прочие поставщики, связи и зависимости отыграть интерфейсами. Сделать абстрактных наследников, реализующих собственно генерацию. И реальных наследников, дающих инстансы. Видится реализуемым. Вообще всё зависит от потребностей и конкретных задач. Обычно, на периферии, там где живут интерфейсы и стыки модулей, объектные модели не бывают сложными, так как стараются не накручивать логику раньше времени. Если входить оттуда и использовать Podam для генерации, будет удобно. Вот реальный
public abstract class MyAbstractDataProviderStrategy implements DataProviderStrategy
Можно базу, прочие поставщики, связи и зависимости отыграть интерфейсами. Сделать абстрактных наследников, реализующих собственно генерацию. И реальных наследников, дающих инстансы. Видится реализуемым. Вообще всё зависит от потребностей и конкретных задач. Обычно, на периферии, там где живут интерфейсы и стыки модулей, объектные модели не бывают сложными, так как стараются не накручивать логику раньше времени. Если входить оттуда и использовать Podam для генерации, будет удобно. Вот реальный
пример полей объекта результата банковской авторизации
private Long amount = null;
private String currencyCode = null;
private Date date = null;
private String authCode = null;
private Long refNumber = null;
private Long hostTransId = null;
private Long cashTransId = null;
private BankCard card = null;
private Long operationCode = null;
private String terminalId = null;
private String merchantId = null;
private String responseCode = null;
private Long resultCode = null;
private boolean status = false;
private String message = null;
private List<List<String>> slips = null;
private boolean isPrintNegativeSlip = false;
private boolean isTransactionCancelled = false;
private String bankid = null;
Понятно, что реализуемо, но надо доделывать самим… Простейший пример на связи, который мог бы помочь решать данный инструмент:
1. Надо создать N объектов User и рандомно присвоить enum UserType
2. Надо создать M объектов UserGroup, у которых есть enum UserGroupType. Каждой UserGroup надо добавить Users, но таких, чтобы UserType каким-то заданным образом соответствовал UserGroupType.
Насколько я понял, в Podan это делается через отдельную стратегию для зависимости UserType-UserGroupType.
В общем я не говорю, что Podan плох, или надо все делать через сеттеры, просто он умеет не все, что мог бы (имхо).
1. Надо создать N объектов User и рандомно присвоить enum UserType
2. Надо создать M объектов UserGroup, у которых есть enum UserGroupType. Каждой UserGroup надо добавить Users, но таких, чтобы UserType каким-то заданным образом соответствовал UserGroupType.
Насколько я понял, в Podan это делается через отдельную стратегию для зависимости UserType-UserGroupType.
В общем я не говорю, что Podan плох, или надо все делать через сеттеры, просто он умеет не все, что мог бы (имхо).
Использую для похожих целей Gson. Просто храню кучу JSON'ов в тестовых ресурсах, из которых набиваются бины. Удобно тестировать Dozer маппинги — на входе два JSON документа. Ассерты пока, правда, руками пишу.
Gson замечательная библиотека по приведению json к объектной модели, но она, увы, не даёт рандомизации и, в Вашем случае, приходится создавать ручками json-ы с фиксированными значениям в дереве. Если приходится писать ассерты на каждую пару классов в маппинге, то попробуйте через Generic-и — мне думается, что можно написать один ассерт. Ну или я не понял Вашей задачи.
Sign up to leave a comment.
PODAM Java объекты для Unit-тестирования