Стоит ли писать тесты, которые работают с браузером (например, с помощью selenium или чего-то еще)?

довольно очевидно, что стоит писать тесты для вещей, которые происходят на стороне сервера, но я слышал, что очень сложно написать модульный тест для UI-материалов и что они хрупкие и ненадежные. Я хотел бы иметь больше уверенности в том, что изменения, которые я делаю, не нарушают основные части страниц импорта на моем сайте.

какие-либо мысли или переживания?

6
selenium unit-testing

5 ответов

Я использовал их как часть развития. классная вещь о них заключается в том, что вы можете выполнить их также в IE(для этого вам нужен сервер selenium). Я использовал их только на стадии разработки и не рассматриваю их как модульные тесты. если я делаю определенную логику UI, они помогают много.

самое главное-назначить id всем используемым html-элементам. без него тесты очень хрупкие. используя комментарии помогают.

2

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

распространенной ошибкой является использование UI-тестов в качестве замены других тестов. Теоретически вы можете протестировать много функций с помощью тестов пользовательского интерфейса, но с этим подходом возникает много проблем. Для начала, некоторые функции могут быть очень жесткими тестировать непосредственно в UI (особенно в исключительных условиях). Во-вторых, если тест не удается, часто трудно понять, в чем источник проблемы. Наконец, чем больше путей кода Вы тестируете в тестах пользовательского интерфейса, тем медленнее становятся тесты пользовательского интерфейса. Если вы полагаетесь только на медленные тесты, ваша производительность ухудшается, что увеличивает соблазн просто "временно" отключить сломанные тесты.

мой совет-протестировать как можно больше в модульных тестах и интеграционных тестах, создать хорошее разделение между вашим пользовательским интерфейсом и вашей бизнес-логики, и использовать тесты пользовательского интерфейса, чтобы поймать / предотвратить ошибки, которые не могут быть протестированы в других видах тестов.

если у вас много тестов, подумайте о создании нескольких наборов. Я создаю один набор для тестов пользовательского интерфейса, один для интеграционных тестов и один для модульных тестов. Модульные тесты очень быстрые, поэтому я запускаю их при разработке кода (часто через TDD). Эти тесты помогают мне быть продуктивным.

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

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

LoginPage loginPage = new LoginPage(selenium);
HomePage homePage = loginPage
    .enterUserName(TestUsers.Alice.USER_NAME)
    .enterPassword(TestUsers.Alice.PASSWORD)
    .submit();
assertThat(homePage.getBreadcrumbs(), equalTo("Home"));
4

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

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

3

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

Да, они хрупкие, и да, его боль держит сумасшедшие селекторные пути, работающие правильно...

1

вы можете использовать browsershots.org чтобы проверить внешний вид ваших страниц практически в каждом браузере.

0