ТЭ
Это тост?
Size: a a a
2020 December 16
АА
😁
2020 December 18
IP
Коллеги, поступила потребность сделать очень нетривиальный тест.
Один и тот же тестовый сценарий в unittest/selenium нужно прогонять синхронно в нескольких потоках. Кто-нибудь такое делал?)
Что можно почитать по этому поводу?
Один и тот же тестовый сценарий в unittest/selenium нужно прогонять синхронно в нескольких потоках. Кто-нибудь такое делал?)
Что можно почитать по этому поводу?
СС
параметризуй пустотой, запусти параллельно
T
Меня смущает синхронно
T
Звучит как просто два треда с кодом и барьерами
B
Коллеги, поступила потребность сделать очень нетривиальный тест.
Один и тот же тестовый сценарий в unittest/selenium нужно прогонять синхронно в нескольких потоках. Кто-нибудь такое делал?)
Что можно почитать по этому поводу?
Один и тот же тестовый сценарий в unittest/selenium нужно прогонять синхронно в нескольких потоках. Кто-нибудь такое делал?)
Что можно почитать по этому поводу?
Нагрузочное делаете таким образом?
B
Мы недавно делали на 300 потоков один сценарий. Заюзал драматург + родной докер контейнер + кубер. И вперёд.
GG
Как ощущения от драматурга?
B
супер
OC
Коллеги, а как вы работает с БД объекта тестирования? Задача: построить независимые api автотесты (хотя бы уменьшить зависимость). То есть в идеале, при операциях с сущности в тест-классе(тест наборе), эта сущность(или список объектов) чистится в БД.
По сути, варианта здесь 3:
1) использовать API (после проверки на создание, можно дернуть удаление) - можно, при условии что подобные вещи стабильны;
2) решать это на уровне тест дизайна/тестовых данных - можно, но это ручная работа, а значит ошибки;
3) дропать бд - хороший вариант, но не восстанавливать же ее из дампа перед каждым тестом/набором?
4) писать ORM для тестируемых сущностей и оперировать через нее - хороший вариант вплане гибкости и читаемости тестов, но меня гложет ситуация поддержки(как эту ORM поддерживать)
Спасибо!
По сути, варианта здесь 3:
1) использовать API (после проверки на создание, можно дернуть удаление) - можно, при условии что подобные вещи стабильны;
2) решать это на уровне тест дизайна/тестовых данных - можно, но это ручная работа, а значит ошибки;
3) дропать бд - хороший вариант, но не восстанавливать же ее из дампа перед каждым тестом/набором?
4) писать ORM для тестируемых сущностей и оперировать через нее - хороший вариант вплане гибкости и читаемости тестов, но меня гложет ситуация поддержки(как эту ORM поддерживать)
Спасибо!
EB
Я склоняюсь к такому подходу:
1) тестируешь АПИ? создавай контекст на уровень ниже. в датапровайдере (она же сетап фикстура) вызывай ОРМ тестируемых сущностей перед тестом; в конце теста удаляй сущность (ты знаешь, какое у нее уникальное поле)
2) когда создавать контекст? под каждый тест / тест класс / неймспейс? каждый решает сам в зависимости от скорости работы с базой, но я бы подумал в сторону единоразового балк-инсерта в базу, а значит подготовку тестовых данных на уровне session фикстуры.
данные при этом должны создавать уникально, чтобы исключить возможный "грязный" контекст между тест-кейсами
2,1) когда удалять контекст?
если тестовые данные изолированны и уникальны, то можно балк-делит операцией в конце сессии. А еще лучше оставить удаление данных и не удалять их под конец, а оставить для инвестигейшена упавших тестов.
Так когда тогда удалять данные кошерно?
- Перед началом следующего запуска тестов, когда будут чиститься все данные, префикс которых не совпадает с хешем, который ты специально генеришь на каждый запуск сессии
3) дропать бд ок, если данных мало. всегда стоит подумать как начинать предельно тупо и в лоб, если тебе за это ничего не будет.
1) тестируешь АПИ? создавай контекст на уровень ниже. в датапровайдере (она же сетап фикстура) вызывай ОРМ тестируемых сущностей перед тестом; в конце теста удаляй сущность (ты знаешь, какое у нее уникальное поле)
2) когда создавать контекст? под каждый тест / тест класс / неймспейс? каждый решает сам в зависимости от скорости работы с базой, но я бы подумал в сторону единоразового балк-инсерта в базу, а значит подготовку тестовых данных на уровне session фикстуры.
данные при этом должны создавать уникально, чтобы исключить возможный "грязный" контекст между тест-кейсами
2,1) когда удалять контекст?
если тестовые данные изолированны и уникальны, то можно балк-делит операцией в конце сессии. А еще лучше оставить удаление данных и не удалять их под конец, а оставить для инвестигейшена упавших тестов.
Так когда тогда удалять данные кошерно?
- Перед началом следующего запуска тестов, когда будут чиститься все данные, префикс которых не совпадает с хешем, который ты специально генеришь на каждый запуск сессии
3) дропать бд ок, если данных мало. всегда стоит подумать как начинать предельно тупо и в лоб, если тебе за это ничего не будет.
ИС
Коллеги, а как вы работает с БД объекта тестирования? Задача: построить независимые api автотесты (хотя бы уменьшить зависимость). То есть в идеале, при операциях с сущности в тест-классе(тест наборе), эта сущность(или список объектов) чистится в БД.
По сути, варианта здесь 3:
1) использовать API (после проверки на создание, можно дернуть удаление) - можно, при условии что подобные вещи стабильны;
2) решать это на уровне тест дизайна/тестовых данных - можно, но это ручная работа, а значит ошибки;
3) дропать бд - хороший вариант, но не восстанавливать же ее из дампа перед каждым тестом/набором?
4) писать ORM для тестируемых сущностей и оперировать через нее - хороший вариант вплане гибкости и читаемости тестов, но меня гложет ситуация поддержки(как эту ORM поддерживать)
Спасибо!
По сути, варианта здесь 3:
1) использовать API (после проверки на создание, можно дернуть удаление) - можно, при условии что подобные вещи стабильны;
2) решать это на уровне тест дизайна/тестовых данных - можно, но это ручная работа, а значит ошибки;
3) дропать бд - хороший вариант, но не восстанавливать же ее из дампа перед каждым тестом/набором?
4) писать ORM для тестируемых сущностей и оперировать через нее - хороший вариант вплане гибкости и читаемости тестов, но меня гложет ситуация поддержки(как эту ORM поддерживать)
Спасибо!
Третий вариант самый годный. Четвертый больше будет на модульное тестирование похож.
По сабжу. Для клонирования базок уже есть готовые инструменты. Если fs поддерживает copy-on-write, то можно это делать мгновенно и почти без выделения места на диске (на момент копирования, конечно).
По сабжу. Для клонирования базок уже есть готовые инструменты. Если fs поддерживает copy-on-write, то можно это делать мгновенно и почти без выделения места на диске (на момент копирования, конечно).
ИС
В позапрошлый вторник на postgres meetup про что-то похожее рассказывали.
ИС
OC
Спасибо за развернутые ответы и помощь! Буду думать в сторону ОРМ🙂
2020 December 19
VK
Мы недавно делали на 300 потоков один сценарий. Заюзал драматург + родной докер контейнер + кубер. И вперёд.
Так и на js/ts или python заюзали?
B
Ts
2020 December 20
YB
Кто-нибудь пробовал pYppeteer? есть примеры использования? дока у него чёт бедная
GK
Кто-нибудь пробовал pYppeteer? есть примеры использования? дока у него чёт бедная
Хм.. Не пробовал, а в этом вообще есть смысл?