t.me/atinfo_chat Telegram группа по автоматизации тестирования

А как вы автоматизируете Sign Up, какие алгоритмы?

Добрый день. Вопрос такого рода:
каким образом лучше автоматизировать Sign Up?
Скармливать один и тот же емей (логин и т д) нельзя, так как после первого прогона пользователь становится известным системе. Какие существуют алгоритмы решения данной проблемы?
Может каким то образом генерировать емейл, или как то по другому?
Спасибо.

Мы полностью воссоздаём базу данных (с всеми таблицами и исходными тестовыми данными) перед КАЖДЫМ тестом. По-моему, это единственный корректный способ сделать тесты по-настоящему независимыми друг от друга и избежать всевозможных “случайных” падений.

В случае с базой данных H2 (которые мы используем в тестовой среде) это делается элементарно, буквально одной командой:

script drop to 'tmp/db-dump.sql'
runscript from 'tmp/db-dump.sql'
1 Симпатия

А если не доступа к базе(берем частный случай), нет доступа к удалению аккаунта? Есть только Сайнап Пейдж. Как тогда поступать?

Странный у вас случай. А как вы будете проверять, что у вас новый юзер записался в БД без доступа к БД? :smile:
P.S.: Проверка логином, не даст 100% гарантии что юзер записался в БД, он может где то закэшироваться на время.

Есть три основных способа.

  1. После каждого теста удалять пользователя.
    1.1 Через админку, если есть такой функционал.
    1.2 Через удаление записи в БД.
  2. После каждого теста менять пользователю эл. почту.
  3. Перед каждым тестом генерировать новый эл. адрес формата ivan+{guid}@example.com.
2 Симпатий

У меня когда то был такой случай и я на тот момент просто воспользовался возможностью в гугле использовать “+” в адресе. Я мог создавать test+1@gmail.com, test+2@gmail.com, test+3@gmail.com и эти адреса прокатывали + все письма валились в один inbox - test@gmail.com ( адрес понятное дело был другой - это я для примера использую). Но лучше конечно чистить после себя, что бы мусор не собирать.

ИМХО самое правильное решение - чистить базу перед каждым тестом. Если очистка базы занимает слишком много времени - я бы сделал так: во внешний файлик записываем число 0. С каждым тестом увеличиваем его на 1.
Мыло генерим как test<число>@test.com.
Это в случае, если регистрация этого мыла нам не нужна.
Если надо, чтобы на мыло отсылались какие-то письма - тогда делать так, как написал biercoff.
То есть, адрес будет выглядеть как test+<число>@gmail.com.

Кажется, что лучший способ - генерация email + потом проверка в БД.
Чистить бд перед тестами - а если кто-то еще пользуется этой же БД? Тогда уж не чистить, а как-то хранить ее состояние, что еще сложнее.
Не нужно выдумывать каких-то хитростей - сгенерили емейл, проверили в базе.

Другой вопрос,если вам нужно проверять, что что-то приходит на почту после signup(типа подтверждения).
Вот в этом случае - наверное лучше иметь один емейл и чистить данные именно о нем в базе.

Суть понял, спаисбо за ответы.
Лучшим решением будет все таки генерация емейла

Вопрос к ТС, проверяют ли именно то, что в базу записался пользователь? Что именно тестируем?
К вопросу о медленности базы - если мы именно работу с базой не тестируем, то быстрее будет в ее замокать.
По поводу работы через внешний файл - как запасной вариант неплохо, но я бы посмотрел, что можно оставить в самом тесте/сьюте - ушли бы от зависимости на файловую систему да и быстрее в памяти чем через файл, особенно если запросы к нему неоптимизированы.
По поводу генерации - если этот e-mail никак не проверяется, то без проблем, а если нужно для сличения, то тогда придется держать в памяти или в другом месте для повторного доступа.

Нет, база не проверяется, проверяется сам факт сайнапа, переход на соответствующую страницу.
Задачу решил генерацией емейла.

Я обычно генерировал уникальный адрес электронной почты через текущую дату и время.

1 Симпатия

Виртуалки - наше все :smile:
Поднял виртуалку с тестовой базой, прогнал тесты, удалил виртуалку.
Шаблон виртуалки заранее настраивается и изменяется под необходимые нужды.
у нас используется proxmox + openvz контейнеры + chef

Засорять бд тестовыми данными - не ок