Стоит передо мной задача написать около десятка тестов, из них первые два обязательно должны быть первыми - это регистрация и дальнейшие действия после регистрации, без которых работа на сайте не полноценна. При этом последующие тесты должны проходиться на новом юзере.
Так вот, я не могу понять, как мне лучше это реализовать в плане архитектуры. Сейчас у меня сделано так: тесты разделены на 2 группы. 1 группа - неавторизованный, 2 группа - авторизованный. Для авторизованного прописано в setup авторизация в один тестовый аккаунт и в teardown разлогин. Решение мне видится таким: запускать вручную первые 2 теста, затем брать логин зарегистрированного, прописывать в setup и запускать все остальные тесты для авторизованного, но такое решение мне не очень нравится.
Есть ли какие-то другие решения? Может у вас было такое на проекте?
мне же нужен не случайный емейл, а тот, что был при регистрации.
или имеется ввиду то, что делается 1 тест для всей последовательности тестов и в ней переменная?
мне кажется, что мне это не подойдет. У меня часть тестов выполняется в одном аккаунте, часть в другом (всего около 5 тестовых аккаунтов). Если я четко пропишу, что email, это одна генерируемая почта, то тесты будут фейлиться. Либо я чего-то не понимаю. (я новичок, если что)
Я хочу, чтобы тесты были независимы, но при этом можно было прогнать смоук
Из описания я если честно не очень понял в чем проблема если первый тест это регистрация нового юзера, а второй это логин под новым и какие то действия под ним, то я вообще не вижу проблемы. Вы же создаете конкретного юзера, его логин и пароль. Да и если это динамика, данные всегда можно взять из бд или сохранить во временном файле. Или у вам проблемы с хранением тестовых данных?)
когда я создаю юзера, я генерирую почту, она всегда разная
порядок выполнения тестов я не знаю как настроить. у меня все тесты выполняются в произвольном порядке. только если присвоить им разные категории, но удобнее было бы, если бы можно было настроить порядок внутри категории
брать юзера из бд или хранить во временном файле - это какие-то странные решения, мне кажется передача данных в переменной намного проще
На счет данных, идея на пробу, может быть тогда сделать отдельный статический класс, который будет формировать и отдавать нужные данные, которые уже были созданы на протяжении всего тестового прогона?!
Не такое это уже странное решение, вполне нормально зайти в базу посмотреть последнего созданного юзера и использовать его данные. Поверьте выборка из БД будет намного быстрее и стабильнее, чем завязка на зависимость от других тестов. Рекомендация от зависимостей уходить, а не создавать их!
Зависимости делать не надо. Как уже выше посоветовали, в твоём случае нормально разбить на две категории и запускать сначала регистрацию нового юзера, а потом основные тесты под этим юзером.
Логин/пароль юзера хранить во внешнем файле (ini, sqlite или другая БД) - это нормально. Более того - это удобнее, нежели создавать и использовать юзера за один прогон.
Создание юзера лучше вынести в отдельные скрипты, которые пишут в БД логины готовых юзеров. Тогда тесты ты сможешь прогнать под любым из них. При этом, естественно, тесты можно будет прогонять повторно без обязательного создания нового юзера.
если юзера брать из базы(последний, который зарегился), то не будет уверенности, что это именно тот юзер, который мне нужен. У нас много юзеров регается. Можно конечно искать совпадение по почте…, но это опять завязка на переменной
если например я храню данные юзера во временном файле, то тоже надо писать, в каком случае мне использовать при авторизации временный файл, а в каком нет. Или это все проще, чем с переменной? я еще не имела дела с такими файлами
я правильно поняла, что в файл записываются все юзеры, которые регистрировались ранее когда-либо по тесту? При прогоне теста с авторизацией берется один из этих юзеров из файла, а затем этого юзера можно удалить? Если этих юзеров можно разделить по дате регистрации и еще по каким-нибудь параметрам, то это отличное решение. Проблема в том, что у нас функционал для разных групп пользователей отличается.
Так можно генерировать по какому-то паттерну, например testautomation_somegroup_12355523@mail.com, и потом искать только емейлы, которые начинаются на testautomation c вхождением в какую-то группу somegroup, которая будет определяться в тесте.
В зависимости от тестируемого приложения можно сделать по-разному:
можно брать юзеров даже из базы самого приложения
плюс: юзеры уже созданы
плюс: юзеры всегда актуальны. Например, если БД приложения периодически обновляется, тестовые юзеры не разойдутся с юзерами, под которыми можно реально работать в приложении
минус: приходится завязываться на структуру БД тестируемого приложения
можно создавать юзеров непосредственно во время теста
плюс: создаются только те юзеры, которые нужны для тестирования. Не делается лишняя работа
этот способ подходит, если у приложения есть соответствущий API. Тогда создание тестовых данных происходит довольно быстро (обычно)
создавать тестовые данные через UI во время теста обычно очень долго. Такие тесты будут выполняться медленно, что очень плохо
можно хранить заранее созданные тестовые данные (fixtures) и использовать их во время тестов
плюс: тестовые данные создаются один раз, а используются многократно
минус: необходимо в тестовом фреймворке иметь дополнительный функционал по выборке нужных тестовых данных для теста. Например, пользователя с ролью, у которого уже есть созданные объекты нужного типа и т.п. Хотя этот минус спорный.
минус: если БД тестируемого приложения периодически обновляется, фикстуры придется пересоздавать заново каждый раз. Поэтому в этом случае их создание нужно автоматизировать
Для начала лучше сильно не заморачиваться. Если тестов пока не много, можно юзеров тупо привязывать к тестам. Типа, user1 - для теста 1, user2_1, user2_2 - для теста 2 и т.д. В тесте 1 соответственно брать данные для user1 и т.д
Для хранения фикстур мне лично понравилось использовать SQLite - это такая легкая БД, которая не требует установки и все данные БД хранит в одном файле. Работать с ней можно как с любой другой БД, через JDBC (не знаю какой аналог этого на .Net) и это не сложнее, чем работать с файлом. К тому же один такой файлик легко таскать и хранить вместе с самим проектом автотестов. Поэтому, если решишься на хранение фикстур, то очень рекомендую использовать SQLite.
Если этот способ тебя пугает, то конечно лучше бы, чтоб тебе с первоначальной настройкой помог опытный разработчик. Но вообще, инструкций в инете много, при желании сможешь и сама разобраться.
Если же решишь использовать способ 2 (создание юзера во время теста), то можно реализовать это двумя способами:
сделать класс в котором есть метод, создающий (регистрирующий) пользователя в системе и возвращающий его данные
либо использовать юзеров, оставшихся от тестов на регистрацию. Для этого они должны сохранять после себя данные о созданных пользователях в некоторой статической структуре данных, например, в static поле какого-нть класса, например TestData. Ну либо читать из БД
У каждого способа есть свои плюсы и минусы, при выборе нужно исходить из того, как это будет использоваться в дальнейшем
Подобное встречал, лично мы не делили тесты на авторизированный и не асторизированнай … а изначально это критическая и не критическая логика. Сам пользователь выступал как некий обьект который создавался в начале тести и жил по ходу прохождения и наполнения данными. Для начала придумайте Test Design
создавать юзера в начале теста и потом его использовать не очень хорошо, т.к. для конкретного теста возможно придется делать еще кучу действий. Например, я не могу сделать действие 5, без действий 1-4. Действия объемные и делать их каждый раз для прогона одного действия неправильно. лучше взять юзера, у которого уже сделаны пункты 1-4
Кстати, кому интересно
В итоге сделали так: берем юзера из базы, для каждого теста прописаны условия, какого юзера брать. Не завязываемся на одном и том же юзере
testomat.io управление авто тестами
если первый тест это регистрация нового юзера, а второй это логин под новым и какие то действия под ним, то я вообще не вижу проблемы. Вы же создаете конкретного юзера, его логин и пароль. Да и если это динамика, данные всегда можно взять из бд или сохранить во временном файле. Или у вам проблемы с хранением тестовых данных?)
*