Комментарии 13
Добрый день! Я правильно понимаю, что для тестов вы используете только Postman, без авто ?
Добрый. Авто есть на 3 разных уровнях. В авто тестах так же используем апи для создания пользователей. Собственно кеширование и задумывалось для автотестов.
Я тогда не совсем понял, какую задачу вы решали (
Раньше на каждый чих вы создавали нового пользователя и это было долго. Поэтому вы переиспользуете старых пользователей, которые "чистые" и их можно брать для тестов ?
Если подытожить, то раньше на создание уходило 15 и более секунд. Сейчас если тест дергает ручку GET 100 миллисекунд на создание. Профит я думаю вполне понятен.
А рассматривали варианты, сделать
тестового пользователя, для условных get запросов, через тестовый фреймворк и дёргать его там , а не через бд? Или хранить пользователя в своей бд и оттуда его брать? Хранить id пользователя в файле при запуске тестов, если тесты особенно параллельны. И так далее.
Просто не было понятно, почему вы пришли к такому решению с redis, ещё и не совсем надёжном, так как с ваших слов кто-то может из тестеров "поломать" пользователя. Почему не рассматривалм "стандартные" решения для вашей проблемы и если рассматривали, то к чему пришли/какие проблемы были?
"Пользователя в файле" - в дальнейшем коллеги забывают обновлять, да и файл очень быстро разрастается у пользователя очень много параметров помимо id. Приводил ответ от api по созданию пользователей — в лучшем случае это только треть информации которую она отдает.
В текущих реалиях бд от редиса в нашем кейсе не слишком сильное различие будет, единственное, что с бд работать несколько сложнее(подключить редис это одна строчка кода и около 10 строчек конфигурации, с бд так не прокатит). Ну и каждые N-дней происходит вайп серверов(flushall явно покороче чем truncate table).
За почти 9 месяцев обращались со "сломанными" пользователями 3 раза. Один из этих раз из-за нестабильно работающей тестовой среды после вайпа.
А можно уточнить чем редис не надежный?(на самом деле у нас под капотом Redis Sentinel, с 3 репликами. Просто подумал что это излишняя информация. =))
Если данные в кэше хранятся аж 40 дней, то отсюда вытекает, что формат данных пользователей меняется не часто, так почему тогда из на своей стороне не замокать? Не написать генератор пользователей с фейкером?
Я запутался в цифрах:
как в разы уменьшить время прохождения автотестов
создание пользователей занимает часов 8
уменьшили ... на 40 минут — с 4 часов до 3 часов 20 минут
Или 8 часов это в сумме и вы запускаете тесты в... 12 параллельных потоков?
1) Нвши автотесты, оказывается, были не совсем авто и требовали ручных шагов, и это было долго. Вау, кто бы мог подумать! Прям неожиданно как-то.
2) Примерно через полсекунды после прочтения истории про создание нового клиента для каждого теста мне пришла мысль про возможное переиспользование. Но оказывается, это тоже было "вау, оказывается!"
3) Непонятно, зачем нужен кэш, ведь должен быть стандартный механизм типа "найти клиента по id". Хотя кэш, конечно, и тут быстрее, но про стандартный способ автор ничего не написал, и как уже написал автор, кэш не отражает любые изменения клиента.
4) можно пойти дальше и объединить/переиспользовать не только шаг создания клиента, но и целые последовательности шагов. Например, есть группа тестов, которые требуют клиента с кредитной картой, у которой не нулевой баланс (сделаны покупки). Соответственно, можно 1 раз создать клиента, добавить ему карту, сделать транзакции по карте и дальше выполнить несколько общих тестов для этого случая. Профит.
5) Идут ли какие-то тесты параллельно? Это же самый общий способ ускорить процесс.
Перефразируя известное изречение, все быстрые тесты быстры одинаково, все медленные — медлены по-своему :)
И, соответственно, многие истории ускорения — зачастую не универсальный совет другим, а отчёт о работе над ошибками, иногда полезным и коллегам по цеху (хотя бывают и исключения: 2 последние статьи про оптимизации прогонов от wrike мне показались интересными)
а почему не пойти дальше не создавать в ci пользователей на этапе деплоя сервиса. еще можно держать копию бд которая на начало дня содержит 1000 созданных юзеров, которые расходуются на тесты, а ночью накатывается новая база. ну и еще я не верю что для 1000 тестов надо создавать пользователя, почти наверняка хватит меньше десятка на все кейсы.
Как в разы уменьшить время прохождения автотестов?