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

Архитектура проекта по автотестированию Selenium тестов вместе с Rest тестами

Теги: #<Tag:0x00007f9afa088120> #<Tag:0x00007f9afa088058> #<Tag:0x00007f9afa187f58> #<Tag:0x00007f9afa187e68>

Всем привет. Есть приложение в котором надо будет тестировать взаимодействие с интерфейсом пользователя, а тажке надо будет тестировать 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) и в них подтягивать эту библиотеку хелперов. Затем каждый класс с тестами будет использовать только то что ему надо, вместо того чтоб тянуть менеджер с ненужным функционалом.

А у фабрики из приложения что лежит под капотом?

А меня данный вопрос волновать не будет: фабрику будет апдейтить разработчик. Наличие адекватно написанных и использующихся юнит-тестов - залог актуальности и работоспособности фабрики :slight_smile:

Хм, странная фабрика получается - вообще-то они используются для создания объектов, но не для сохранения их в базу. Вы уверены что разработчики не поменяют ее поведение на реально соответствующее паттерну “фабрика”? Насколько я понял, у вас в фабриках пока есть скрытое поведение - они мало того что создают объект, так еще и сохраняют его в БД. Или я Вас неправильно понял?

Navar4eg, да примерно так и хочу сделать: реализацию тестовых методов сделать для GUI в классах страниц, а реализацию тестовых методов для API, DB сделать в хелперах в отдельных пакетах API, DB и т.д., разделённых по контексту. А в менеджере планирую реализовать вспомогательную логику, такую как получение вебдрайвера, ленивую инициализацию страниц, хелперов, пробрасывание свойств, снятие скриншотов и т.д.
Только вот раздумываю, делать ли третий уровень для описания бизнес логики или описывать её в классах страниц(для GUI). Склоняюсь к тому, что бы не делать, т.к. будет дублирование методов, или может вынести в отдельные веб хелперы, разделённые на контексты бизнес логику…?.

Структура в парочке моих проектов на огурце
Cucumber Scenario -> Steps -> (Page Objects, Rest Helpers, DB helpers)
Отдельно всякие общие вещи (WebDriver management и.т.д)

1 Симпатия

Скорее всего, кода говорили “фабрика” имелось ввиду (https://en.wikipedia.org/wiki/Test_fixture)
Эти методы могут быть как в проекте так и импортироваться отдельно.

Я считаю не принципиальным разносить 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 Симпатия