'assert' vs. 'verify' in Selenium

Question

The checks Selenium performs usually come in two flavours: assertFoo and verifyFoo. I understand that assertFoo fails the whole testcase whereas verifyFoo just notes the failure of that check and lets the testcase carry on.

So with verifyFoo I can get test results for multiple conditions even if one of them fails. On the other hand, one failing check for me is enough to know, that my edits broke the code and I have to correct them anyway.

In which concrete situations do you prefer one of the two ways of checking over the other? What are your experiences that motivate your view?

Answer 1

I would use an assert() as an entry point (a "gateway") into the test. Only if the assertion passes, will the verify() checks be executed. For instance, if I'm checking the contents of a window resulting from a series of actions, I would assert() the presence of the window, and then verify() the contents.

An example I use often - checking the estimates in a jqgrid: assert() the presence of the grid, and verify() the estimates.

Answer 2

I've come across a few problems which were overcome by using

assert*()

instead of

verify*()

For example, in form validations if you want to check a form element, the use of

verifyTrue(...);

will just pass the test even if the string is not present in the form.

If you replace assert with verify, then it works as expected.

I strongly recommend to go with using assert*() .

Answer 3

如果您在生产系统上运行 Selenium 测试并希望确保您以测试用户身份登录，而不是您的个人帐户，那么在触发任何如果意外使用会产生意想不到的效果的动作。

Answer 4

Usually you should stick to one assertion per test case, and in this case the difference boils down to any tear-down code which must be run. But you should probably put this in an @After method anyway.

I've had quite a few problems with the verify*() methods in SeleneseTestBase (eg they use System.out.println() , and com.thoughtworks.selenium.SeleneseTestBase.assertEquals(Object, Object) just doesn't do what you expect) so I've stopped using them.