Одной из самых больших проблем с тестами веб-интерфейса является их хрупкость. Перемещение элемента страницы или замена поля ввода выпадающим списком может вызвать волновой эффект, который нарушает десятки ваших тестов.
В этой статье я покажу вам, как инкапсулировать детали реализации пользовательского интерфейса, чтобы ваши тесты могли сосредоточиться на тестировании функций.
Я буду использовать web tau framework , в котором есть примитивы, предназначенные для помощи в тестировании хрупкости
Давайте протестируем функцию поиска в воображаемом приложении.
scenario('search by specific query') {
browser.open('/search')
$('#search-box').setValue('search this')
$('#search-box').sendKeys("\n")
$('#results .result').count.shouldBe > 1
}
Тест:
- открыть страницу поиска
- задайте значение для поля ввода, которое можно найти по идентификатору поля поиска
- имитируйте клавишу ввода и проверьте, есть ли какие-то результаты
Я утверждаю, что должна быть только одна причина для изменения этого теста, и это в том случае, если фактическая функциональность вашего поискового интерфейса изменится ( Принцип единой ответственности кто-нибудь? ).
Однако есть четыре нефункциональные причины, которые могут заставить наш тест измениться:
- изменение URL-адреса страницы поиска
- способ, которым мы инициируем поиск, меняется: клавиша ввода против мыши щелчок
- идентификаторы/классы/атрибуты, связанные с элементами, изменяются
- время отклика сервера замедляется
Давайте рассмотрим их один за другим.
В web tau $(css) создается экземпляр Элемента страницы , который вы используете для имитации действий пользователя и значений запроса.
Созданные экземпляры являются ленивыми и могут быть определены еще до открытия браузера.
def searchBox = $('#search-box')
def numberOfResults = searchBox.count
scenario('search by specific query') {
browser.open('/search')
searchBox.setValue('search this')
searchBox.sendKeys("\n")
numberOfResults.shouldBe > 1
}
Это шаг в правильном направлении, но у нас все еще есть открытый URL страницы и жестко закодированный Нажмите клавишу Enter .
Давайте создадим метод отправки, чтобы инкапсулировать способ, которым пользователи должны инициировать поиск.
def searchBox = $('#search-box')
def numberOfResults = searchBox.count
scenario('search by specific query') {
submit('search this')
numberOfResults.shouldBe > 1
}
def submit(query) {
browser.open("/search")
searchBox.setValue(query)
searchBox.sendKeys("\n")
}
Я думаю, что внесенные нами изменения облегчают рассуждения о тестировании. Но я все еще хочу сделать последний штрих: переместить определения из тестового файла, чтобы их можно было потенциально использовать в других тестовых сценариях.
Давайте перенесем определения элементов действия и страницы в отдельный класс. Возможно, вы уже слышали о концепции Page Object раньше.
В webta объекты страницы являются простыми экземплярами класса. Именно ленивый характер Элемента страницы делает возможной такую простоту.
package pages
import static com.twosigma.webtau.WebTauDsl.*
class SearchPage {
def searchBox = $('#search-box')
def numberOfResults = $('#results .result').count
def submit(query) {
browser.open("/search")
searchBox.setValue(query)
searchBox.sendKeys("\n")
}
}
Это не имеет значения, когда мы создаем экземпляр класса, так как поле поиска и numberOfResults будут запущены лениво.
Давайте создадим Страницы класс со статическими экземплярами объектов страницы, чтобы было удобно получать к ним доступ из разных сценариев.
package pages
class Pages {
static final def search = new SearchPage()
static final def calculation = new CalculationPage()
static final def form = new FormPage()
}
Наш объект страницы находится на расстоянии одного импорта.
import static pages.Pages.*
scenario("search by specific query") {
search.submit("search this")
search.numberOfResults.shouldBe > 1
}
Наш тест теперь усилен и может выдерживать нефункциональные изменения пользовательского интерфейса. Но есть одна незащищенная область, оставшаяся незакрытой.
Во время локальной разработки наш сервер работает невероятно быстро, а результаты поиска выдаются менее чем за 5 мс. Недели спустя мы запустим тесты в среде контроля качества и, скорее всего, будем иметь дело с неудачным утверждением.
Давайте проведем заключительное тестовое подкрепление.
import static pages.Pages.*
scenario("search by specific query") {
search.submit("search this")
search.numberOfResults.waitToBe > 1
}
Мы заменили должно Быть с ждите , Чтобы Быть . В результате вместо того, чтобы сразу выполнить утверждение с ошибкой, подождите, пока будет запрашиваться numberOfResults несколько раз, пока не истечет время ожидания (зависит от конфигурации).
Я использовал Groovy для тестирования за последнее десятилетие и я думаю, что он идеально подходит для этой работы. Но если вы не являетесь поклонником Groovy , вы можете использовать Java или другие языки JVM.
Если вы заинтересованы в Java или других примерах JVM, пожалуйста, напишите мне в комментариях, и я буду рад помочь.
GitHub
Введение в тестирование REST API с помощью web tau
Оригинал: “https://dev.to/mykolagolubyev/web-ui-tests-reinforcement-with-webtau-framework-selenium-based-1g3k”