【问题标题】:Spock test in GEB cookies using where clause使用 where 子句在 GEB cookie 中进行 Spock 测试
【发布时间】:2018-10-20 20:20:42
【问题描述】:

我已经配置了一些 geb 测试,以根据我的网络应用程序中的登录尝试检查不同的消息。由于消息和输入字段将在第三次登录尝试时发生变化。

登录是基于发送到特定电话号码的密码的两步登录,因此在第一页 LoginPage 中,用户介绍了他们的 IdphoneNumber ,然后它被重定向到第二个页面ValidationLoginPage,用户在其中介绍收到的密码。

我想检查,在第二页中,用户只能输入三个错误密码,并且在第四次尝试输入密码时,输入密码的输入将消失,并显示一条不同的消息,表明不再尝试。

为了检查这一点,我准备了一个测试,它在 given: 子句中引入了 IdphoneNumber,并使用 where: 子句引入了 3 次错误密码.由于where: 重复所有测试,我尝试使用where: 中的注入变量来控制部分重复,所以我有类似的东西:

def "Test max loging attempts"(){
  given:
    if(loginAttempt == 1)
      to LoginPage
      loginModule.startLogin(cfg.user.id,cfg.user.phone)
    }
  when:
    at LoginValidationPage
    assert  $('div.box_id_header h3').text() == 'Verify your code'
    assert  $('#code').css('display').contains('block')
    loginModule.verifyPassword('WRONGPASSWORD')
  then:
    at LoginValidationPage
    println "Attempt ${loginAttempt}"
    if(loginAttempt == 4){
      // last attempt
      assert    $('#code').css('display') == 'none' 
      assert  $('#divCodeErrorMsg').text().contains('No more attempts')
    }else{
      assert    $('#code').css('display').contains('block')
      assert  $('#divCodeErrorMsg').text().contains('Wrong password. Try again.')
    }
  where:            
    loginAttempt << (1..4)
}

我的问题是,每次where: 迭代都会清除cookies,我认为消息和行为不是我所期望的。我不想在GebConfig.groovy 文件中配置autoClearCookies=false,因为我还有另一个需要此功能的测试。有一种方法可以避免使用 spock def setupSpec() {} 方法清除此方法的 cookie 并在 def cleanupSpec() {} 方法中重新激活?

此外,还可以以更简洁的方式使用where:,避免检查loginAttempt 变量以避免多次运行given: 部分,或者有更好的方法根本不使用where:

【问题讨论】:

    标签: cookies where-clause spock geb


    【解决方案1】:

    问题是您可能会误解并因此滥用 Spock 的 where: 块。它旨在对特征方法进行参数化,并且该方法的每次运行都包含一个独立的特征。如果您 @Unroll 您的功能,即使对于每组 where: 参数,也会生成一个新方法。因为特性应该相互独立并且理论上能够以任何给定的顺序甚至并行运行,所以需要重置测试夹具才能运行它们。这就是您的 cookie 发生的情况,因为您滥用 where: 功能来实现一个简单的循环。

    您的代码中还有其他一些小问题,例如when: 块中未声明的at 检查。即使at 产生false,如果你不使用assert 也没有任何后果。您只能在 then:expect: 块中跳过 assert,但不能在 given:when: 中跳过,也不能在我将在示例代码中使用的闭包或辅助方法中跳过。

    这个怎么样?

    package de.scrum_master.stackoverflow.foo
    
    import geb.spock.GebReportingSpec
    
    class LoginTest extends GebReportingSpec {
      def loginModule = new LoginModule()
      def cfg = new Config()
    
      def "Test max login attempts"() {
        given: "we are at the login page"
        browser.config.autoClearCookies = false
        to LoginPage
    
        when: "logging in 4x with wrong credentials"
        (1..4).each {
          loginWithWrongCredentials(it, it < 4)
        }
    
        then: "we get a 'no more attempts' error message"
        $('#codi').css('display') == 'none'
        $('#divCodiValidacioError').text().contains('No more attempts')
      }
    
      def loginWithWrongCredentials(int loginAttempt, boolean checkForWrongPasswordMessage) {
        println "Login attempt ${loginAttempt}"
        loginModule.startLogin(cfg.user.id, cfg.user.phone)
        assert at(LoginValidationPage)
        assert $('div.box_id_header h3').text() == 'Verify your code'
        assert $('#code').css('display').contains('block')
        loginModule.verifyPassword('WRONGPASSWORD')
        assert at(LoginValidationPage)
        if (checkForWrongPasswordMessage) {
          assert $('#codi').css('display').contains('block')
          assert $('#divCodiErrorMsg').text().contains('Wrong password. Try again.')
        }
      }
    }
    

    我还建议将内容断言从 loginWithWrongCredentials 移动到 LoginValidationPage 的辅助方法中,它们更属于它们,并从测试中调用它们。

    【讨论】:

    • 我同意这个问题中的代码似乎在滥用 where: 块,这些块应该用于参数化而不是循环。请注意,如果仅启用了 implicit assertions,则不必在检查时断言。
    • 很好,@erdi! OTOH,您是 Geb 之神,我只是偶尔的用户。所以我不打算在这里争论。 ;-)
    • 哎呀...你完全正确,我试图使用where: 保持测试清晰...现在我意识到where: 是运行参数化测试。就像@RunWith(Parameterized.class) 在junit 中做的那样。感谢您的回复。
    【解决方案2】:

    最后在setup 步骤中禁用autoClearCookies 我得到了所需的行为。

    def setup() {
        browser.getConfig().setAutoClearCookies(false)      
    }
    

    但令人惊讶的是,如果我使用 setupSpec() 方法,它似乎不起作用,因为只有第一个 where: 迭代有 autoClearCookies=false,其余有 autoClearCookies=true

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2014-08-02
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2017-12-31
      • 1970-01-01
      相关资源
      最近更新 更多