【问题标题】:'assert' vs. 'verify' in SeleniumSelenium 中的“断言”与“验证”
【发布时间】:2011-08-10 06:33:53
【问题描述】:

Selenium 执行的检查通常有两种形式:assertFoo 和 verifyFoo。我知道 assertFoo 未能通过整个测试用例,而 verifyFoo 只是记录了该检查的失败并让测试用例继续进行。

因此,使用 verifyFoo,即使其中一个条件失败,我也可以获得多个条件的测试结果。另一方面,对我来说,一次失败的检查就足以知道我的编辑破坏了代码,无论如何我都必须更正它们。

在哪些具体情况下,您更喜欢两种检查方法中的一种而不是另一种?您的哪些经历激发了您的观点?

【问题讨论】:

  • Selenium webdriver api 或 junit 没有所谓的“验证”。 Selenium IDE 已验证。

标签: testing selenium integration-testing


【解决方案1】:

我会使用assert() 作为测试的入口点(“网关”)。只有当断言通过时,才会执行verify() 检查。例如,如果我正在检查由一系列操作产生的窗口的内容,我会assert() 窗口的存在,然后verify() 内容。

我经常使用的一个示例 - 检查 jqgrid 中的估计值:assert() 网格的存在,verify() 估计值。

【讨论】:

    【解决方案2】:

    我遇到了一些问题,通过使用解决了

    assert*()

    而不是

    verify*()

    例如,在表单验证中,如果要检查表单元素,则使用

    verifyTrue(...);
    将通过测试,即使该字符串不存在于表单中。

    如果您将 assert 替换为 verify,那么它会按预期工作。

    我强烈建议使用assert*()

    【讨论】:

    • 我假设您的意思是第三个示例中的 assertTrue()?
    【解决方案3】:

    如果您在生产系统上运行 Selenium 测试,并希望确保您以测试用户身份登录,而不是您的个人帐户,那么最好先断言正确的用户已登录在触发任何意外使用会产生意外影响的操作之前。

    【讨论】:

      【解决方案4】:

      通常你应该坚持每个测试用例一个断言,在这种情况下,差异归结为任何必须运行的拆卸代码。但无论如何你应该把它放在@After 方法中。

      我在使用 SeleneseTestBase 中的 verify*() 方法时遇到了很多问题(例如,它们使用 System.out.println(),而 com.thoughtworks.selenium.SeleneseTestBase.assertEquals(Object, Object) 并没有达到您的预期)所以我已经停止使用它们。

      【讨论】:

      • 但是每个测试用例只有一个断言会使测试变得非常慢,因为 selenium 必须为每个断言启动和停止浏览器实例(在我的笔记本电脑上每个测试用例最多可以使用 15 秒)。你如何解决这个问题?
      • 我在测试之间共享 selenium 实例,请参阅 stackoverflow.com/questions/5626103/…。但公平地说,我也有很多带有多个断言的测试,例如当我测试一个表单的所有字段都正确更新时。
      • 什么是验证?我在junit中找不到任何用于验证的api。
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2013-09-09
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多