testomat.io управление авто тестамиВсем привет. Есть приложение в котором надо будет тестировать взаимодействие с интерфейсом пользователя, а тажке надо будет тестировать Rest api. Подскажите как запроектировать тесты. С GUI вроде бы всё понятно - использовать Selenium, разделить тестовую логику и вспомогательную и реализовать page object, но как можно сюда интегрировать Rest тесты? Библиотеку планирую использовапть Rest assured. Может быть есть какие то примеры?
Уже пробегала похожая тема месяца эдак 3…4 назад.
Я бы не пытался объединить коня и трепетную лань. Это разные уровни тестов (системный и интеграционный соответственно).
Выносите максимум тестов на интеграционный уровень, всё, что не получится покрыть там - оставляйте на системный уровень.
В плане проектов - это должны быть 2 разных проекта, поскольку общего между ними совсем немного.
Если хочется, чтобы все тесты запускались по тычку на 1 кнопку - сделайте master джобу, которая будет запускать 2 тестовые джобы соответственно.
1 лайк
Согласен с рекомендацией покрывать больше на интеграционном уровне.
Не согласен что нельзя REST с UI смешивать в тестах.
Это правильно и эффективно когда используешь тот интерфейс который соответствует целям теста.
Например выполнить предусловия через REST и потом проверить результат на UI.
Для прекондишенов ИМХО лучше использовать фабрики, чем REST. Во-первых, быстрее, а, во-2-х, что главное, понятнее. Ну или чистый SQL.
Прекондишен типа UserFactory.CreateUser (“vasya”, “password”) гораздо понятнее, чем какой-нибудь POST с аттачем, в котором описывается юзер Вася.
Да, всё верно - должна быть абстракция над REST методом.
Но по сути тест вызовет REST API
что то вроде
@Test
public void doSomething()
{
restClient.createUser(“Vasja”,“password”);
loginScreen.enterUser(“Vasja”)
loginScreen.enterPassword(“password”)
}
Можно, конечно, под капотом держать и REST. Но зачем?
Если нет возможности взять фабрики из аппликухи (из тех же юнит тестов, к примеру) - то под капот проще положить SQL, чтобы не использовать лишнюю прослойку и не быть от неё зависимым.
Если SQL хранится вместе с тестами отдельно от кода, то он запросто может устареть и тесты будут вставлять невалидные данные.
REST endpoint обычно предоставляет само приложение и, если устареет то как REST вызывается из теста, то скорее взорвётся тест, а не база данных
1 лайк
Думаю инициализировать в мэнеджере отдельные хелперы для работы с rest, базой данных, http. А для работы с GUI там же инициализирую страницы.
Если под “менеджером” Вы подразумеваете класс-фасад над хелперами для инициализации всего и сразу - то не стоит так делать. У Вас так супер-менеджер получится. Как следствие - или он будет слишком мало уметь, или количество методов в нем будет зашкаливать. Однозначно, использовать его будет неудобно.
Я могу порекомендовать такой подход: вынести все эти “хелперы” в отдельный модуль, а классы по признаку контекста (REST, DB, …) разнести в нем по разным пакетам. Для тестов создать два отдельных модуля (скажем, UI и API) и в них подтягивать эту библиотеку хелперов. Затем каждый класс с тестами будет использовать только то что ему надо, вместо того чтоб тянуть менеджер с ненужным функционалом.
А у фабрики из приложения что лежит под капотом?
А меня данный вопрос волновать не будет: фабрику будет апдейтить разработчик. Наличие адекватно написанных и использующихся юнит-тестов - залог актуальности и работоспособности фабрики 
Хм, странная фабрика получается - вообще-то они используются для создания объектов, но не для сохранения их в базу. Вы уверены что разработчики не поменяют ее поведение на реально соответствующее паттерну “фабрика”? Насколько я понял, у вас в фабриках пока есть скрытое поведение - они мало того что создают объект, так еще и сохраняют его в БД. Или я Вас неправильно понял?
Navar4eg, да примерно так и хочу сделать: реализацию тестовых методов сделать для GUI в классах страниц, а реализацию тестовых методов для API, DB сделать в хелперах в отдельных пакетах API, DB и т.д., разделённых по контексту. А в менеджере планирую реализовать вспомогательную логику, такую как получение вебдрайвера, ленивую инициализацию страниц, хелперов, пробрасывание свойств, снятие скриншотов и т.д.
Только вот раздумываю, делать ли третий уровень для описания бизнес логики или описывать её в классах страниц(для GUI). Склоняюсь к тому, что бы не делать, т.к. будет дублирование методов, или может вынести в отдельные веб хелперы, разделённые на контексты бизнес логику…?.
Структура в парочке моих проектов на огурце
Cucumber Scenario -> Steps -> (Page Objects, Rest Helpers, DB helpers)
Отдельно всякие общие вещи (WebDriver management и.т.д)
1 лайк
Скорее всего, кода говорили “фабрика” имелось ввиду (Test fixture - Wikipedia)
Эти методы могут быть как в проекте так и импортироваться отдельно.
Я считаю не принципиальным разносить API методов в отдельный проект, если они используются только в UI тестах.
Но если есть отдельно API тесты лучше вынести их в отдельный проект и импортировать API методы в проект с UI тестами.
В .Net это можно сделать с помощью проектов в одном солюшене, в джаве вроде с мавеном как-то нужно решать этот вопрос (делать приватный мавен репозиторий или что-то в этом роде? думаю тебе могут подсказать это отдельно)
Проще конечно все в одно месте держать )
В чём принципиальность необходимости разнесения?
Религия не позволяет вместе API и UI тесты держать?
А если серьёзно есть тесты и есть их цель.
Если для достижения этой цели эфективно вызвать через REST - подлазишь через REST
Надо на UI проверить - лезешь через UI
Нет REST, а есть база и надо выставить некоторое состояние - SQL INSERT и погнали
есть хорошая статейка Seven Steps to Automation Success
там этот вопрос расматривается в Champion Product Testability
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.471.9363&rep=rep1&type=pdf
1 лайк