Перейти к содержимому

Фотография

API и UI в одном флаконе


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 14

#1 MissLeman

MissLeman

    Постоянный участник

  • Members
  • PipPipPip
  • 152 сообщений


Отправлено 20 августа 2018 - 07:33

Как правильно написать автоматизированный тест, где одновременно есть действия на UI и запросы через API? Можно ли задействовать в одном проекте, скажем, Frisby и Protractor? Не будет ли это монстр.

 

(пример теста - в браузере открываем УРЛ, пользователю отображается окно "Вы согласны предоставить приложению такому-то доступ к таким-то данным?", пользователь жмет "Согласен", дальше в УРЛ получаем авторизационный код, с его помощью access token (через oauth api), а затем с токеном через рест апи проверяем выполнение каких-то действий. но это не единственный тест, где требуется сочетание действий апи и ui).


  • 0

#2 Noksa

Noksa

    Активный участник

  • Members
  • PipPip
  • 117 сообщений
  • ФИО:Александр

Отправлено 20 августа 2018 - 08:18

Не очень понятен вопрос, что вы понимаете под фразой "правильно написать автоматизированный тест"?

 

У меня, например, тест после запуска лезет в БД приложения, и если не находит там подходящие данные, грузит их туда посредством отправки запросов через апи.

 

Всё это в тесте выглядит как одна строка

var order = GetOrderFromDb(orders.Service._24, DBStaticDataForTests.OrdersInfo.OrderType.CourierDeliveryOnCourierAny,
true, TestsData.OrdersGoodsNum, true, false);

Что вам мешает делать нечто подобное?

 

Ну а внутри уже реализация может быть и громоздкой, либо опять же разбита на более мелкие вызовы.


  • 0

#3 MissLeman

MissLeman

    Постоянный участник

  • Members
  • PipPipPip
  • 152 сообщений


Отправлено 20 августа 2018 - 08:43

Не очень понятен вопрос, что вы понимаете под фразой "правильно написать автоматизированный тест"?

Эффективно. По фэншую. Да даже здесь на форуме вон недавно был вопрос - хочу тестировать апи селениумом + как-то там еще ужасно, человеку покрутили у виска и написали: гуглить вот это, делать вот так. Не хочется, образно говоря, как в той байке, надевать штаны с разбега, чтобы потом узнать, как это делают нормальные люди.

 

А так ничего не мешает, конечно, у меня описанный мной тест тоже укладывается в 6 строк.


  • 0

#4 Spock

Spock

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 772 сообщений
  • ФИО:Роман

Отправлено 20 августа 2018 - 09:20

 

 

(пример теста - в браузере открываем УРЛ, пользователю отображается окно "Вы согласны предоставить приложению такому-то доступ к таким-то данным?", пользователь жмет "Согласен", дальше в УРЛ получаем авторизационный код, с его помощью access token (через oauth api), а затем с токеном через рест апи проверяем выполнение каких-то действий. но это не единственный тест, где требуется сочетание действий апи и ui).

этот тест и правда не требует вебдрайвера. Если мы тестируем "выполнение каких-то действий через рест апи используя токен" - то можно этот токен получить через тот же самый рест апи


  • 0

#5 Freiman

Freiman

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 591 сообщений
  • ФИО:Андрей Адеркин
  • Город:Йошкар-Ола

Отправлено 20 августа 2018 - 09:35

Вопрос такой: а что мы проверяем, API или UI?
Если UI, и без API-запросов не получается подготовить окружение, то смешиваем API и UI. Не самое элегантное решение, но бывает и хуже.
Если тестируем API, но для подготовки окружения требуется UI, то это плохо. Надо понять, нужны ли вам реально здесь UI-тесты, или можно поведение пользователя эмулировать другим способом.
  • 0

#6 Spock

Spock

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 772 сообщений
  • ФИО:Роман

Отправлено 20 августа 2018 - 09:47

 

 

сли UI, и без API-запросов не получается подготовить окружение, то смешиваем API и UI. Не самое элегантное решение, но бывает и хуже.

так вроде же наоборот, смешивать это бест практис. Например если тест проверяет например отображение какой-то записи в таблице, то совершенно отлично можно создать запись через РЕСТ, потом открыть страничку браузером и проверить данные, потом удалить запись через РЕСТ


  • 1

#7 Freiman

Freiman

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 591 сообщений
  • ФИО:Андрей Адеркин
  • Город:Йошкар-Ола

Отправлено 20 августа 2018 - 09:51

так вроде же наоборот, смешивать это бест практис. Например если тест проверяет например отображение какой-то записи в таблице, то совершенно отлично можно создать запись через РЕСТ, потом открыть страничку браузером и проверить данные, потом удалить запись через РЕСТ

Это ж подготовка тестовых данных, а не часть теста.
  • 0

#8 QuadBit

QuadBit

    Новый участник

  • Members
  • Pip
  • 48 сообщений

Отправлено 20 августа 2018 - 11:06

Речь шла скорее о тесте, который после создания какой-нибудь записи проверит её и на фронте селениумом и на беке посредством апи фреймворка. Можно ещё и в БД залезть, что мелочиться :smile: По делу - это сходу нарушает принцип 1 тест - 1 проверка, не говоря о абсолютно неизбежном повышении сложности -> хрупкости теста. Я бы начал с ответа на вопрос "А зачем" и посмотрел, оправдывает ли цель все сопутствующие сложности. Из практики я такое видел 1 раз - написали после того как проект сдали и изменений более не планировалось фундаментальных. Использовалось как приемка, обойтись спокойно могли и без них. Хотя сейчас перечитав первоначальный пост, понял, что возможно другое имеется в виду.


  • 0

#9 MissLeman

MissLeman

    Постоянный участник

  • Members
  • PipPipPip
  • 152 сообщений


Отправлено 20 августа 2018 - 12:32

(пример теста - в браузере открываем УРЛ, пользователю отображается окно "Вы согласны предоставить приложению такому-то доступ к таким-то данным?", пользователь жмет "Согласен", дальше в УРЛ получаем авторизационный код, с его помощью access token (через oauth api), а затем с токеном через рест апи проверяем выполнение каких-то действий. но это не единственный тест, где требуется сочетание действий апи и ui).

этот тест и правда не требует вебдрайвера. Если мы тестируем "выполнение каких-то действий через рест апи используя токен" - то можно этот токен получить через тот же самый рест апи

 

Извините, я не знаю, как процитировать только ваш ответ, без моей цитаты. Что касается теста, то его цель именно в проверке получения токена по гранту authorization_code. т.е. надо проверить, что этот самый диалог показывается, кнопки на нем нажимаются, грубо говоря. а дальнейшие дествия с рест апи через токен нужны для проверки валидности последнего.


  • 0

#10 MissLeman

MissLeman

    Постоянный участник

  • Members
  • PipPipPip
  • 152 сообщений


Отправлено 20 августа 2018 - 12:42

Вопрос такой: а что мы проверяем, API или UI?
Если UI, и без API-запросов не получается подготовить окружение, то смешиваем API и UI. Не самое элегантное решение, но бывает и хуже.
Если тестируем API, но для подготовки окружения требуется UI, то это плохо. Надо понять, нужны ли вам реально здесь UI-тесты, или можно поведение пользователя эмулировать другим способом.

Наш продукт - два приложения, связанные друг с другом через апи. Первое приложение меняет параметры второго. Поэтому надо проверить, что после выполнения таких-то действий через апи во втором приложении поменялось то-то и то-то.

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

 

Я бы начал с ответа на вопрос "А зачем" и посмотрел, оправдывает ли цель все сопутствующие сложности.

 

У нас, как и в вашем примере, это, скорее всего войдет в приемочное тестирование.
Ну и я пока в процессе, посмотрю, как оно пойдет. Руками это все проверять тоже удовольствие из средних.


  • 0

#11 BadMF

BadMF

    Специалист

  • Members
  • PipPipPipPipPip
  • 809 сообщений
  • ФИО:Dmitry Petrov

Отправлено 20 августа 2018 - 14:56

 

1) Извините, я не знаю, как процитировать только ваш ответ, без моей цитаты.

 

2) Что касается теста, то его цель именно в проверке получения токена по гранту authorization_code. т.е. надо проверить, что этот самый диалог показывается, кнопки на нем нажимаются, грубо говоря. а дальнейшие дествия с рест апи через токен нужны для проверки валидности последнего

 

1) это просто, можно удалить в своём 

2) по феншую, вам надо отдельно проверять работоспособность выдаваемого токена и тест действий пользователя для этого. сейчас у вас тестсюит получился а не тест.


  • 0

#12 Сергей

Сергей

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 245 сообщений
  • Город:Москва

Отправлено 20 августа 2018 - 15:09

MissLeman, как Вы иначе пройдете авторизацию oauth2.0 без UI? Я бы первый тест сделал авторизацию через UI, остальные тесты через api. Авторизация не прошла, тесты не гоняем. Можно первый тест засунуть в подготовку ТД.
  • 0

"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс


#13 MissLeman

MissLeman

    Постоянный участник

  • Members
  • PipPipPip
  • 152 сообщений


Отправлено 20 августа 2018 - 15:51

1) это просто, можно удалить в своём 

2) по феншую, вам надо отдельно проверять работоспособность выдаваемого токена и тест действий пользователя для этого. сейчас у вас тестсюит получился а не тест.

 

1) Оказывается эта фишка в ФФ не работает, а я думала, все знают какой-то секрет. Пришлось в Хром переехать. Ну да ладно. Спасибо большое.

2) О, точно кстати. JWT же можно распарсить и завалидейтить. приложенька в браузере для этого есть, значит и библиотечка найдется :)  :victory:

 

MissLeman, как Вы иначе пройдете авторизацию oauth2.0 без UI? Я бы первый тест сделал авторизацию через UI, остальные тесты через api. Авторизация не прошла, тесты не гоняем. Можно первый тест засунуть в подготовку ТД.

Ну да. Эта штука с согласием пользователя только в одном гранте. В остальных (password, client_credentials) UI не требуется, там грант получается через один запрос. Но это, как я уже говорила, только пример.

 

Есть и другие тесты типа: через API поменять некий параметр приложения (через UI этого нельзя сделать), потом проверить, что конечный пользователь видит именно то, что нужно. Это, вероятно, проходит как подготовка тестовых данных и, стало быть, тапками меня не закидают.


  • 0

#14 Spock

Spock

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 772 сообщений
  • ФИО:Роман

Отправлено 20 августа 2018 - 19:33

 

 

Есть и другие тесты типа: через API поменять некий параметр приложения (через UI этого нельзя сделать), потом проверить, что конечный пользователь видит именно то, что нужно. Это, вероятно, проходит как подготовка тестовых данных и, стало быть, тапками меня не закидают.

1. тест "поменять через апи" выглядит так: через апи меняем значение, смотрим респонс и потом через гет в том же апи проверяем что значение действительно засетилось

2. тест "пользователь видит значение" выглядит так: открываем браузер и через UI смотрим значение

 

то есть тут 2 теста у вас, один тестирует изменение данных через АПИ, другой тестирует отображение данных в пользовательском интерфейсе


  • 1

#15 MissLeman

MissLeman

    Постоянный участник

  • Members
  • PipPipPip
  • 152 сообщений


Отправлено 21 августа 2018 - 16:11

Спасибо всем за ответы.


  • 0


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных