Comments 10
1) Названия проекта и пакета по умолчанию - неудачные, особенно dasha
2) В начале заявлена цель - декларативность, а потом идёт сплошной код.
3) Неужели для такой распространенной задачи нашёлся только одна библиотека?
4) Для большинства сложных проектов используют слепки базы данных из прода, где в какой-то степени "замазаны" чувствительные данные. А иначе замучаешься генерить.
1) Возможно, возможно стоит сделать ребрендинг :). Название dasha использовал в честь имени дочери, по праву создателя проекта.
2) Наверное согласен, пожалуй даже скорректирую текст;
3) Библиотеки как оказались есть, одну указали в одном из комментариев к статье https://github.com/instancio/instancio . Как ни странно, уже после начала работы над своим проектом я её не нашел, точнее в 2021 году ее еще не было. Нашел большое сходство идей, которые заложил в свою библиотеку я и авторы instancio. Но процесс уже пошел и решил продолжить работу - составить им конкуренцию. Некоторые вещи мне кажется я сделал более удачно, у меня есть Dsl у них Model. Мой Dsl это в сущности собранные вместе Model для использования это удобно;
4) Эта тема очень обширная, для больших систем, интеграционных тестов и пр. действительно используются слепки БД с прода. Мы их тоже используем, на это все накладываются куча ограничений административных и ограничения безопасности и т.д и т.п. Я создавал библиотеку в которой в одном месте (`Dsl`) задает параметры для генерации объектов "на лету".
Под все указанные требования подходит библиотка: https://github.com/instancio/instancio
Почему вы решили вместо неё писать свой вариант?
Спасибо, я ждал этот вопрос :) Ответ простой, в 2021 году когда начал впервые работать над проектом genthz,я ее попросту не нашел. Прямо сейчас я посмотрел, история репозитория instancio началась в 03.03.2022 . Многие идеи у нас совпадают.
Одну вещь я у них спер :) это использование getter'ов и setter'ов вместо строковых имен полей, при указании специфических генераторов для них (у меня это [FieldMatchers](https://github.com/mathter/genthz/blob/dev/3.1.x/genthz-core/src/main/java/org/genthz/FieldMatchers.java) у них Select#field(...)).
Точно могу сказать, что документация у них пока что лучше :)
Библиотека хорошая, но определенные моменты, с точки зрения использования, мне кажутся у меня более удачными и более прозрачными. Например, у меня, как мне кажется, все более единообразно, нет этого огромного количества методов stream - отдельно для стрима, ofList - отдельно для листов, у меня всегда единнобразно ObjectFactory.get(List.class, String.class) ObjectFactory.get(List.class, Person.class.
P.S. В конечном итоге я решил пустить этот проект в большое плавание и только использование другими покажется насколько удачные решения я заложил в проект.
ObjectFactory.get(List.class, String.class)
А дженерики тут вместо параметров никак?
В текущей версии нет, в принципе можно передавать сразу java.lang.reflect.Type, но с точки зрения количества букв в коде это будет не сильно меньше, поскольку это самый Type как то необходимо сконструировать, например при помощи org.apache.commons.lang3.reflect.TypeUtils.
objectFactory.get(Map<String, Person>.class)В scala думаю что так сделать можно.
А есть где-нибудь сравнение библиотеки с аналогичными решениями. Я обычно easy random использую, есть ещё куча других по моему
Я рекомендую также взглянуть на scalacheck, возможно, подкинет дополнительные идеи. Там тестовый фреймворк с генерацией данных.
Генератор тестовых данных для JVM совместимых языков