2016-05-09 3 views
3

Это может показаться странным вопросом, потому что я не видел ни одного онлайн-обсуждения или учебников, поэтому я предполагаю, что люди обычно не делают этого, но есть ли хорошие варианты для автоматическое приемочное тестирование, когда критерии приемки являются конкретными сетевыми запросами, отправленными веб-приложением в результате конкретных взаимодействий пользователей? В качестве самого простого примера пользователь нажимает кнопку, а код javascript на странице отправляет запрос ajax. Команда QA хочет быть уверенным, что запрос действительно отправлен и что он имеет определенные параметры. Теперь одним типичным решением было бы полностью игнорировать сетевые запросы и вместо этого проверять изменения интерфейса, возникающие в результате такого запроса, но что, если запрос не вызывает немедленных изменений интерфейса? Другой типичный подход заключается в том, чтобы перенести такое тестирование на уровень unit-test или уровень интеграции-тестирования, но что, если QA скорее увидит, что он работает в реальном браузере.Приемочные испытания сосредоточены на исходящих HTTP-запросах

Итак, каковы были бы варианты написания автоматических приемочных испытаний, которые начинаются с некоторого взаимодействия с пользователем в браузере, а затем утверждают, что ожидаемый сетевой запрос был отправлен? Какой инструмент понадобится для такого тестирования (насколько я понимаю, Selenium не может сделать это сам по себе)? Знаете ли вы о каких-либо доступных примерах такого тестирования (проекты с открытым исходным кодом, которые его реализовали, руководства, описывающие, как это сделать и т. Д.), Или вы могли бы предложить подробный пример?

ответ

1

Похоже, что вы хотите сделать, выкрикнуть Ajax-вызовы из вашего приложения переднего конца в ваших тестах. Это довольно легко сделать в эти дни с библиотеками, такими как Sinon, Angular's httpBackend, или jQuery Mockjax (библиотека, которую я поддерживаю).

Вы можете прочитать о теме немного больше в blog post Я написал некоторое время назад, но основная идея - перехватить запрос Ajax до того, как он попадет на основной интерфейс JavaScript XMLHttpRequest (таким образом, отправив сетевой запрос). В ваших тестах JS вы можете затем проверить перехватчик, чтобы узнать, был ли сделан сетевой запрос и что ему было дано.

Не зная ваш технический стек (инфраструктура JS, среда тестирования и т. Д.), Трудно точно сказать, как вы это настроили, но посмотрите на инструменты, упомянутые выше.

+0

Благодарим вас за ответ. Но то, что вы описываете, издеваясь над аякс-звонками, звучит немного ниже, чем то, что я имел в виду. Если вы используете httpBackend от Angular, то (если я не ошибаюсь), запросы даже не достигнут реального бэкэнда, и вам придется повторно выполнить все ответы бэкэнда в макете. Нет, я имел в виду, что у вас полнофункциональное веб-приложение, при этом клиент подключается к реальному бэкэнду, но имеет возможность проверять запросы, отправленные клиентом. – azangru

+0

Например, я использовал webdriver.js для управления браузером, а также node-http-mitm-proxy, чтобы перехватывать и проверять сетевой трафик между браузером и бэкэнд и отчитываться перед тестовым бегуном о том, что запрос с определенными параметрами действительно отправлено. Кажется, он работает, но выглядит довольно громоздким и хрупким, поэтому мне было интересно, существуют ли какие-то более эффективные инструменты или стратегии для такого тестирования. – azangru

+0

Хм ... Я понимаю, что вы говорите, но почему вы проверяете, что сетевой запрос был отправлен _ отправлен _? Вам почему-то нужно проверить сетевое оборудование? Если нет, почему бы просто не проверить параметры, отправленные в запрос Ajax, используя насмешливую библиотеку? Это удаляет муфту на бэкэнд, что делает ваши тесты более быстрыми. Да, требуется больше настроек, но в итоге более стабильна. – jakerella

Смежные вопросы