Удаленка для jenkins+selenide+selenoid+allure+docker спецов на 2-3 часа в день. 100% remote! Присоединиться к проекту

Какой фреймворк выбрать для создания тестов selenium + API

visual-studio
api
nunit
allure
webdriver
Теги: #<Tag:0x00007fedbb95a938> #<Tag:0x00007fedbb95a708> #<Tag:0x00007fedbb95a528> #<Tag:0x00007fedbb95a370> #<Tag:0x00007fedbb95a230>

(Lelik) #1

Добрый день!

Сложно было придумать название темы, попыталась максимально приблизить к смыслу топика.
Вопрос вот в чем. У меня есть веб клиент серверное приложение. Планирую создавать Ui тесты с использование selenium+ nunit, VS+С# , отчеты Allure.
НО. Это приложение является частью большой системы. Благодаря микро-сервисам, данные попадают в это приложениеиз другого большого веб-приложения, у которого своих UI тестов нет. Т.е. мне нужно взять создать “precondition” и они должны быть не асбстрактными (а созданные под мои конкретные условия).
Есть несколько вариантов решения, на мой взгляд. Использовать API для создания входящих тестовых данных, но они не дают покрытия все 100% тестовых случаев. использовать интеграционные тесты (девелоперов).
Поэтому вопрос. Что лучше и проще вкрутить в “тест проект”, вызовы апишек или интеграционные тесты и какие библиотеки возможо будут полезны?


(Igor Balagurov) #2

Мне кажется, что хорошая практика для end-to-end UI\API тестирования делать precondition более низкоуровневый и максимально близко к тестируемому слою(например: для UI теста - через API, к которому обращается приложение), а не лезть по каждому случаю в базу.

Это позволяет:

  • Писать тесты именно на проверяемый сервис\слой(локализация дефектов)
  • Не ловить баги на том, что к примеру что-то схеме базы\взаимодействии сервисов, которые не являются предметом проверки поменяется и теперь до теста нужные данные не доходят. (Может у вас для какого-то случая цепочка вызовов микро-сервисов и только потом что-то в базе берётся\пишется.)

Может потребуется для вашего случая использовать API нескольких сервисов, чтобы все предусловия желаемые получить, а может будет более эффективно большинство проверок на уровень интеграции(или даже юнит-тестов) вынести - тут сильно от проекта зависит, обсудите с командой разработки - со стороны только общие пожелания(капитанство) могу высказать:

  • Проверяйте всё на максимально низком уровне (пример: различные классы эквивалентности каких-нибудь полей через API или даже unit-тесты, где непосредственно идёт работа с этими полями)
  • На UI выносите классы эквивалентности характерные для UI(собственно пирамиду тестирования лучше не шатать)

Для тестирования API на C# могу посоветовать - http://restsharp.org/