Тесты пользовательского интерфейса могут быть медленными, хрупкими и болезненными для обслуживания, но некоторые ошибки могут быть обнаружены только в тестах пользовательского интерфейса. Важный вопрос не в том, стоит ли писать тесты пользовательского интерфейса, а в том, чтобы сделать ваши тесты полезными, стабильными и поддерживаемыми.
Распространенной ошибкой является использование тестов пользовательского интерфейса в качестве замены других тестов. Теоретически, вы можете протестировать множество функциональных возможностей с помощью тестов пользовательского интерфейса, но есть много проблем с этим подходом. Для начала, некоторые функции могут быть очень трудно протестировать непосредственно в пользовательском интерфейсе (особенно в исключительных условиях). Во-вторых, если тест не пройден, часто трудно понять, в чем причина проблемы. Наконец, чем больше путей кода вы тестируете в тестах пользовательского интерфейса, тем медленнее становятся тесты пользовательского интерфейса. Если вы полагаетесь только на медленные тесты, ваша производительность ухудшается, что увеличивает искушение просто «временно» отключить неработающие тесты.
Мой совет - как можно больше тестировать в модульных тестах и интеграционных тестах, создавать хорошее разделение между вашим пользовательским интерфейсом и бизнес-логикой, а также использовать пользовательские тесты для выявления / предотвращения ошибок, которые невозможно проверить в других видах тестов. .
Если у вас много тестов, рассмотрите возможность создания нескольких наборов. Я создаю один набор для тестов пользовательского интерфейса, один для интеграционных тестов и один для модульных тестов. Модульные тесты очень быстрые, поэтому я запускаю их по мере разработки своего кода (часто через TDD). Эти тесты помогают мне быть продуктивным.
Интеграционные тесты, которые я запускаю реже (возможно, после внесения некоторых изменений). Тесты пользовательского интерфейса, которые я запускаю, когда я готовлюсь к отправке изменений (или, когда я пишу больше тестов пользовательского интерфейса, очевидно).
Последний совет: подумайте о написании тестов пользовательского интерфейса на специфичном для домена языке . Это облегчает понимание тестов (потому что они читаются как набор пользовательских шагов, а не как набор низкоуровневых действий браузера). Это также может облегчить поддержку кода. Например, вместо того, чтобы каждый тест проходил пошаговые действия браузера для входа в систему, вы можете увидеть:
LoginPage loginPage = new LoginPage(selenium);
HomePage homePage = loginPage
.enterUserName(TestUsers.Alice.USER_NAME)
.enterPassword(TestUsers.Alice.PASSWORD)
.submit();
assertThat(homePage.getBreadcrumbs(), equalTo("Home"));