Комментарии 11
Привет
Отличная примерная статья, что запиливать проект автотестов чаще всего нужно сразу на сгенерированные данные, если это возможно.
Но у меня возникло пару вопросов.
1) Генерируете ли вы сейчас что-то помимо записей в БД? Ведь помимо данных в бд нужно помнить о файлах (документы в S3 условно), настройках сервисов, данных в брокере сообщений и так далее.
2) У вас чистая база данных на тестовых контурах или в ней присутствуют данные с прода? Вы зачищаете тестовые (сгенерированные данные) после тестов?
3) Как обстоят дела с интеграциями? Также генерируете ответы внешних сервисов по средствам моков или генерируете данные в бд на основе "реальной" интеграции?
4) Есть запил на параллелизацию, чтобы ускорить прогоны? Каким образом будете достигать консистентности БД и бороться с параллельным чтением и записью?
Привет!
Спасибо за вопросы.
1) Нет, кроме объектов в БД мы ничего не генерируем. Ну может еще для тестирования функционала с шинами мы создаем нужное нам сообщение.
2) У нас обезличенный слепок прода. Т.к. с тестовыми средами проблем нет, то тесты запускаются свеженькой бд. Перед ночным прогоном обновляется бд и версия системы.
3) Интеграций не так много; какие-то на нас почти не оказывают влияния, некоторые заглушены с помощью wiremock.
4) Вот при старом подходе нельзя было сделать параллельный запуск. Сейчас в эту сторону можно думать. Сначала будут переводиться те наборы тестов, которые не взаимодействуют с БД. Проблемы явно будут, но нужно приступить к этому))
Перед ночным прогоном обновляется бд и версия системы.
Вот про версию системы. Вы просто катите ветку мастера на тест? А если фича не дотестирована, то просто перезатирается в пользу актуальной? Или это вообще с кодом разработки не связано?
Ночной прогон запускается на мастере и свежеразвернутой бд в автоматическом режиме.
Прогон из смоук-набора запускается на каждый пул реквест, но на эту же ночную БД (работаем над тем, чтобы убрать это).
Полный прогон на тестируемой ветке QA может запустить сам, но перед этим развернуть БД и приложение.
Я очень надеюсь, что ваш генератор данных не очень случайный, а инициализируется константой. Чтобы повторный его запуск генерил идентичный датасет.
Если это не так, то вы своими руками вносите элемент случайности в тесты. Тот самый, от кторого хотели уйти.
Это не генератор случайных чисел. Это скорее фабрика объектов.
Из случайного там заполнения поля Комментарий у некоторых сущностей в формате "Generated by Autotests_{DataTIme.Now}".
Именно поэтому поведение всегда идентично, сколько бы раз вы не запускали тест)
У меня в практике был случай, когда тесты фейлились раз в году. При переводе поясного времени вперёд.
С одной стороны прикольно и позволило отловить редчайший баг. С другой - даже вставка Now в параметры даёт невоспроизводимое поведение и возможна ситуация, когда результат теста плавает.
Если бы у нас тесты падали в раз год, то этой статьи бы не было))
Я ловил только на генерации суммы от 0 (это нельзя было) до 1, но здесь падал каждый сотый раз, если активно крутить, то довольно часто видишь.
Ну понятно, что раз в год - это по конкретно данной причине. В целом тестам свойственно падать.
Но не слишком часто. Красный билд - это всё-таки исключительная ситуация. Вот люди над светофорами заморачиваются:
https://habr.com/ru/articles/169097/
Я как раз занимаюсь генерацией тестовых данных на системах банка(клиенты, счета, кредиты, и т.д.), и пишу АТ( платформа UT3 на Oracle).
Сам вопрос генерации ТД снимает очень много вопросов по тестированию, от нагрузочного, до интеграционного.
Конечно, наш подход — это не универсальное решение, а лишь один из способов решения проблемы.
По-любому молодцы!
Как генерация тестовых данных вернула доверие к тестам