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

rest
webdriver
java
selenium
Теги: #<Tag:0x00007fedbb989c88> #<Tag:0x00007fedbb989af8> #<Tag:0x00007fedbb989968> #<Tag:0x00007fedbb989788>

(Elvis Presley ) #1

Всем привет. Есть приложение в котором надо будет тестировать взаимодействие с интерфейсом пользователя, а тажке надо будет тестировать Rest api. Подскажите как запроектировать тесты. С GUI вроде бы всё понятно - использовать Selenium, разделить тестовую логику и вспомогательную и реализовать page object, но как можно сюда интегрировать Rest тесты? Библиотеку планирую использовапть Rest assured. Может быть есть какие то примеры?


(Дмитрий Мирошник) #2

Уже пробегала похожая тема месяца эдак 3…4 назад.
Я бы не пытался объединить коня и трепетную лань. Это разные уровни тестов (системный и интеграционный соответственно).
Выносите максимум тестов на интеграционный уровень, всё, что не получится покрыть там - оставляйте на системный уровень.
В плане проектов - это должны быть 2 разных проекта, поскольку общего между ними совсем немного.
Если хочется, чтобы все тесты запускались по тычку на 1 кнопку - сделайте master джобу, которая будет запускать 2 тестовые джобы соответственно.


(Vjacheslav Lukashevich) #3

Согласен с рекомендацией покрывать больше на интеграционном уровне.
Не согласен что нельзя REST с UI смешивать в тестах.
Это правильно и эффективно когда используешь тот интерфейс который соответствует целям теста.
Например выполнить предусловия через REST и потом проверить результат на UI.


(Дмитрий Мирошник) #4

Для прекондишенов ИМХО лучше использовать фабрики, чем REST. Во-первых, быстрее, а, во-2-х, что главное, понятнее. Ну или чистый SQL.
Прекондишен типа UserFactory.CreateUser (“vasya”, “password”) гораздо понятнее, чем какой-нибудь POST с аттачем, в котором описывается юзер Вася.


(Vjacheslav Lukashevich) #5

Да, всё верно - должна быть абстракция над REST методом.
Но по сути тест вызовет REST API

что то вроде

@Test
public void doSomething()
{
restClient.createUser(“Vasja”,“password”);

loginScreen.enterUser(“Vasja”)
loginScreen.enterPassword(“password”)

}


(Дмитрий Мирошник) #6

Можно, конечно, под капотом держать и REST. Но зачем?
Если нет возможности взять фабрики из аппликухи (из тех же юнит тестов, к примеру) - то под капот проще положить SQL, чтобы не использовать лишнюю прослойку и не быть от неё зависимым.


(Vjacheslav Lukashevich) #7

Если SQL хранится вместе с тестами отдельно от кода, то он запросто может устареть и тесты будут вставлять невалидные данные.
REST endpoint обычно предоставляет само приложение и, если устареет то как REST вызывается из теста, то скорее взорвётся тест, а не база данных


(Elvis Presley ) #8

Думаю инициализировать в мэнеджере отдельные хелперы для работы с rest, базой данных, http. А для работы с GUI там же инициализирую страницы.


(Alexandr Navara) #9

Если под “менеджером” Вы подразумеваете класс-фасад над хелперами для инициализации всего и сразу - то не стоит так делать. У Вас так супер-менеджер получится. Как следствие - или он будет слишком мало уметь, или количество методов в нем будет зашкаливать. Однозначно, использовать его будет неудобно.
Я могу порекомендовать такой подход: вынести все эти “хелперы” в отдельный модуль, а классы по признаку контекста (REST, DB, …) разнести в нем по разным пакетам. Для тестов создать два отдельных модуля (скажем, UI и API) и в них подтягивать эту библиотеку хелперов. Затем каждый класс с тестами будет использовать только то что ему надо, вместо того чтоб тянуть менеджер с ненужным функционалом.


(Alexandr Navara) #10

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


(Дмитрий Мирошник) #11

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


(Alexandr Navara) #12

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


(Elvis Presley ) #13

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


(Vjacheslav Lukashevich) #14

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


(Pasha Strunkin) #15

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

Я считаю не принципиальным разносить API методов в отдельный проект, если они используются только в UI тестах.
Но если есть отдельно API тесты лучше вынести их в отдельный проект и импортировать API методы в проект с UI тестами.

В .Net это можно сделать с помощью проектов в одном солюшене, в джаве вроде с мавеном как-то нужно решать этот вопрос (делать приватный мавен репозиторий или что-то в этом роде? думаю тебе могут подсказать это отдельно)

Проще конечно все в одно месте держать )


(Vjacheslav Lukashevich) #16

В чём принципиальность необходимости разнесения?
Религия не позволяет вместе 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