Всем доброго утра!
Задалась интересным вопросом о удобном хранении тестовых данных для API тестов (например список пользователей и параметры сценария теста).
Ну например, возьмем проект где существует 20 различный ролей пользователей.
Соответственно, минимальные хранимые тестовые данные для каждой роли ( менеджер, админ, гость и т.д.) это логин , пароль и энное число других параметров.
Встречала на проектах разные решения, например, хранение всего этого в testng.xml и передача тесту необходимого пользака через аннотации. Либо, например, создавать класс “пользователь” с полями - логин, пароль и пр… и в прекондишенах к тесту\ тестовому классу создавать экземпляры этого класса и там же их заполнять.
Но в первом случае рассматривать огромную xml где хранятся и тестовые данные и различные параметры запуска и пр. как то по мне не очень удобно и в какой-то момент эта xml может слишком разрастись настолько что необходимо будет уделять большое время для ее актуализации. (а если предположить что мы не только пользователей храним я еще кучу других тестовых данных)
Ну а во втором случае это немного противоречит принципу тесты отдельно - данные отдельно, хотя и все объекты ( в нашем случае пользователи) инициализируются в прекондишенах.
Интересно узнать как организуете хранение (относительно небольших) тестовых данных на проекте вы. Или узнать опыт, когда вам при каких-то обстоятельствах пришлось отказаться от одной структуры хранения данных в пользу другой.
Я данные обычно генерирую во время выполнения, конфигурационные данные в Json храню, если много данных типа юзеров, можно и в базе данных хранить.
1 лайк
Какие конфигурационные данные например?
например: таймауты, baseUrl, браузер, те же username и password (у меня просто нет кучи юзеров). В проектах на javascript Json везде используется, так как это нативный формат
Интересно, а вы храните эти конфиги сгруппированными по тест сьютам ( ну то есть на каждый из кейсов или сьютов свой такой набор конфигов) или просто списком из всех возможных вариантов а из самого теста берете тот параметр который нужен.
Нет, там только базовые настройки для всех тестов. Все остальное генерирую в тестах, хардкодные данные не использую, можно наступить на очень хорошие грабли
А генерируете это всмысле что случайным образом или берете из бд?
Например какой то объект(айтем на сайте) с рандомными полями создаю через апи, а потом его использую в UI тестах, если апи нет, можно попросить разработчиков чтоб скрипты сделали для базы.
Что будет если базу почистятили вы перейдете на новое окружение? Ваши тесты просто перестанут работать. Вам придется потратить много времени чтобы все переносить опять. Но в проде вам такое не позволят делать)
1 лайк
а на счет почистки бд кстати тоже очень интересный вопрос, был как-то проект который вообще очень завязан на данных
и я помню перед тестами у нас проходили скрипты которые проверяли наличие тестовых данных в базе или если они потерты - скрипты их создавали
и только потом запускался тестовый прогон
А в чем суть принципа, если не секрет? Всегда считал, что тестовые данные это часть теста. То, что их зачастую удобнее выносить из тестового класса никак не отменяет данный факт.
Я бы остерегался хранить данные в XML, и упаси боже Excel. Остальное можно пробовать. Даже внутри класса не так страшно держать данные. Некоторые даже считают, что этот принцип удобнее, т.к. все в одном месте лежит. Что-то типа того как делают во Vue.js где html + js + css упаковывают в единый модуль vue. Это я просто привёл как пример, что и такой подход не лишен своих достоинств и имеет право на жизнь. В общем случае я бы рекомендовал смотреть только те места хранения данных, которые покрываются системой контроля версий (текст в git) и избегал бы всяких бинарных штук, типа xls. Ну, и по удобству работы с текстом выбирал самые немногословное и удобное в работе: json, properties, yaml, text, java-class, csv (как аналог вместо xls). Как исключение можно было бы считать вариант с хранением в БД или в докере. Но такие штуки как говорится должны делать специально обученные каскадеры, в смысле автоматизаторы.
Генерация, кстати, норм подход. Ещё есть либы типа фейкера для чего-то подобного. Но тут надо понимать, что это теплое с мягким - Синтетические vs реальные тестовые данные: плюсы, минусы, подводные камни. В смысле может получится как в той шутке про бар, тестировщика и реального пользователя.
2 лайка
В некоторых случаях есть смысл оборачивать данные в объекты. Например, перечисления в Java могут отлично подойти для этих целей. В Java перечисления являются классом и позволяют добавлять методы и поля, для элементов перечислений (которые являются нстансами класса) можно создавать конструкторы. Так, из одного значения инама можно вытаскивать кучу разных типов данных. Получается удобный интерфейс для работы с данными во фреймвроке, не во всех, но в некоторых случаях это удобно)
1 лайк
testomat.io управление авто тестами