утверждать против проверки в Selenium - PullRequest
16 голосов
/ 21 апреля 2011

Проверки, выполняемые селеном, обычно бывают двух видов: assertFoo и verifyFoo. Я понимаю, что assertFoo не проходит весь тестовый сценарий, тогда как verifyFoo просто отмечает неудачу этой проверки и позволяет тестовому сценарию продолжить.

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

Итак, мой вопрос:
В каких конкретных ситуациях вы предпочитаете один из двух способов проверки другого? Какой опыт мотивирует ваше мнение?

Ответы [ 4 ]

16 голосов
/ 21 апреля 2011

Я бы использовал assert() как точку входа ("шлюз") в тест. Только если утверждение пройдет, будут выполняться проверки verify(). Например, если я проверяю содержимое окна в результате ряда действий, я assert() проверю наличие окна, а затем verify() содержимое.

Пример, который я часто использую - проверка оценок в jqgrid: assert() наличие сетки и verify() оценки.

3 голосов
/ 26 марта 2012

Я столкнулся с несколькими проблемами, которые были преодолены с помощью

<code>assert*()

вместо

<code>verify*()

Например, при проверке формы, если вы хотите проверить элемент формы, использование

verifyTrue(...);
просто пройдет тест, даже если строка отсутствует в форме.

Если вы замените assert на verify, тогда он будет работать как положено.

Я настоятельно рекомендую использовать assert * ().

2 голосов
/ 24 февраля 2012

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

1 голос
/ 21 апреля 2011

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

У меня было довольно много проблем с методами verify*() в SeleneseTestBase (например, они используют System.out.println(), а com.thoughtworks.selenium.SeleneseTestBase.assertEquals(Object, Object) простоделать то, что вы ожидаете), поэтому я перестал их использовать.

...