React Test Utils против Selenium WebDriver - PullRequest
Новая
       35

React Test Utils против Selenium WebDriver

0 голосов
/ 18 марта 2019

Мы использовали React JS для внешнего интерфейса, и нам нужно написать сквозные тесты. После исследования в Интернете, мы обнаружили 2 варианта: 

1. Selenium WebDriver
2. React Test Utils (https://reactjs.org/docs/test-utils.html)

Я понял, что с помощью React Test Utils вы можете имитировать щелчки и проверять состояние элементов HTML с помощью таких методов, как findRenderedDOMComponentWithXXX, и что вы можете запускать эти тесты из командной строки, чтобы они были быстрее.

Selenium делает то же самое, но из браузера, он позволит вам написать тест в стиле управляемой поведением (делает его более читабельным)

Моя путаница:

  1. Можем ли мы использовать React Test Utils для тестирования полной веб-страницы (сложного компонента) или лучше тестировать только простые компоненты, изготовленные на заказ. Например: если у нас есть такой компонент, как Задачи, который позволяет вам добавить задачи, удалить задачи, изменить приоритет, который использует такие компоненты, как Input, DropDown и Toggle.

    Так что это хорошая идея - использовать React Test Utils для всего компонента Tasks, или мы должны использовать его для меньших отдельных компонентов, таких как Input, DropDown, Toggle

  2. Чтобы протестировать полный компонент Tasks, запишите сквозные тесты с использованием Selenium.

Некоторые другие пункты:

  1. метод имитации в React Test Utils требует передачи данных о событиях, которые могут увеличить небольшой объем работы.

Будет здорово, если кто-нибудь поможет мне понять разницу между ними.

1 Ответ

2 голосов
/ 26 марта 2019

Вы можете использовать Jest и Selenium вместе. Не ограничивайте себя только одним. Вероятно, вы даже выйдете за рамки этих двух, когда будете заниматься разработкой на основе тестирования или разработкой на основе поведения, основываясь на том, что конкретно вам нужно протестировать. Jest сам по себе не может действительно имитировать UAT, по моему мнению. Вам необходимо открыть браузер, чтобы полностью имитировать взаимодействие с пользователем, но эти тесты браузера могут составлять очень небольшой процент тестов по сравнению со всеми вашими тестами. Причина, по которой так много людей отошло от селена, заключается в громоздкости его конфигурации и обслуживания. Также скорость и надежность.

В последние годы появились новые инструменты для тестирования на основе браузера:

Кукольник

https://github.com/GoogleChrome/puppeteer

Nightwatch.js

http://nightwatchjs.org

Кроме того, ваш конкретный язык программирования предлагает дополнительные функции и улучшения для тестирования. Многие Java-разработчики используют Maven и TestNG при тестировании для создания и отладки своих тестов. Разработчики Ruby могут использовать RSpec. Какой бы тестовый прогон вы ни использовали, он может включать в себя несколько зависимостей от серверной части для всех видов инструментов тестирования: linting, html-проверка, функциональность, DevSecOps, миграция базы данных или даже проверка орфографии. Ключ состоит в том, чтобы сгруппировать все тесты, которые, по вашему мнению, вам понадобятся, в одном тестовом прогоне (желательно или как можно меньше). Затем запустите их все подряд, в конвейере CI / CD; как Дженкинс до развертывания изменений. Если какой-либо из них дает сбой, то ваша сборка дает сбой в режиме реального времени.

Если вы хотите запустить несколько тестов API в конвейере, Ньюман выглядит неплохо, чтобы включить тесты Postman, которые вы, возможно, уже заложили в конвейер CI / CD. Конечно, в качестве альтернативы вы также можете создавать http-клиенты, но не у всех есть набор навыков кодирования, поэтому инструменты, которые вы выбираете в первую очередь, должны дополнять наборы навыков, которые у вас есть.

Smart Bear теперь также имеет несколько инструментов, которые будут работать в конвейере CI / CD для тестирования SOAP и UI, но они намного дороже, чем альтернативы с открытым исходным кодом.

...