Generic DataProvider или как работать с DB сущностями в условиях масштабирования

база знаний
#1

Пожалуй, на текущий момент наиболее популярным является DDT подход в web автоматизации. При хранении тестовых данных в БД зачастую мы пишем различного рода обертки для последующего изъятия необходимых нам записей. Есть сторонники написания абстракций над jdbc. Другие же, подходят к вопросу более обстоятельно, прибегая к уже готовым системам по типу Hibernate или Spring.

Данный пример использует Hibernate для взаимодействия с любым кол-вом сущностей в пределах нескольких БД без привязки к типу. Т.е. это может быть, к примеру, MySQL и Oracle. Текущая реализация предполагает лишь опрерации чтения, но в целом, вы вольны добавить доп. логику записи в generic DAO. Задание сущностей организовано посредством Java 8 ипрувментов в области аннотаций. Пример такого теста:

    @Entity(entity = Users.class, schema = AUTOMATION, ids = {1, 2})
    @Entity(entity = ProdUsers.class, schema = PRODUCTION, invocationCount = 5)
    @Test(dataProviderClass = DataProviderUtils.class, dataProvider = GENERIC_DP)
    public void getFirstSampleData(final Users user, final ProdUsers productionUser) {
        System.out.println(Thread.currentThread().getId() + " thread:\n" +
                "User = " + user + "\n" +
                "Production user = " + productionUser + "\n");
    }

Как всегда, более подробно можно почитать в моем блоге + сорсы на местном GitHub. С любыми предложениями по импрувменту пишите в личку, либо создаем PR.

2 лайка
[Resolved] Как работать с набором тестовых данных для одного теста.
Автоматизация работы с БД
#2

Добавил concurrent updates support. Детальнее в блоге. Обновленные исходники там же, на GitHub. Для примера были созданы 2 теста, которые в параллели изменяют одну и ту же сущность. При этом, на выходе у нас возможны 2 кейса: с перезаписью мейла и без. Но измененный пароль будет всегда merged независимо от порядка выполнения потоков.

    @Entity(entity = Users.class, schema = AUTOMATION, ids = {1})
    @Test(dataProviderClass = DataProviderUtils.class, dataProvider = GENERIC_DP)
    public void saveFirstSampleData(final Users user) {
        user.setEmail("test.user1@email.com");
        user.setPassword("password1");
        user.save();
    }

    @Entity(entity = Users.class, schema = AUTOMATION, ids = {1})
    @Test(dataProviderClass = DataProviderUtils.class, dataProvider = GENERIC_DP)
    public void saveSecondSampleData(final Users user) {
        user.setEmail("test.user3@email.com");
        user.save();
    }
#3

Спасибо. Любопытно.

Мне в последнее время кажется noSql данные удобнее ввиду отсутствия ограничения таблиц, и легкости тестовых данных. Если элемент таблицы может быть список или мапа. Не пробовали?

Как DAO сеттеры и геттеры писать для null значений таблиц, или если нужны defaults (чтобы не засорять sql табличку, не нужными для теста данными)?
В Java 8, появилась Optional монада и сахар для Null, к чему склоняетесь что-то есть у Hibernate?

#4

На прошлом проекте было требование - хранить результаты тестов в MongoDB. Так что я использовал Morphia - аналог Hibernate для MongoDB. Синтаксис очень похож.

Вам необязательно создавать все филды, которые есть в таблице. Hibernate вытянет только то, что объявлено в Entity классе. Или речь не об этом?