如何在Spock Unit测试中使用100%代码覆盖率测试Groovy构造函数

时间:2015-09-04 15:53:30

标签: unit-testing grails groovy spock cobertura

我的问题是:我是Spock测试的新手,我正试图在此用户类上获得100%的代码覆盖率。为了让我开始,有人可以帮我弄清楚如何测试构造函数。我目前所拥有的并不是使用cobertura插件来覆盖它。另外,如果有人对Spock + Cobertura有所了解,也许你可以了解我做错了什么,以及进一步测试的一些指示。

我有一个代表用户的类:

import java.io.Serializable;
import java.util.Set;

class User implements Serializable {
    String email
    byte[] photo

    static hasMany = [lineups: Lineup]

    private static final long serialVersionUID = 1

    transient springSecurityService

    String username
    String password
    boolean enabled = true
    boolean accountExpired
    boolean accountLocked
    boolean passwordExpired

    User(String username, String password) {
        this()
        this.username = username
        this.password = password
    }

    @Override
    int hashCode() {
        username?.hashCode() ?: 0
    }

    @Override
    boolean equals(other) {
        is(other) || (other instanceof User && other.username == username)
    }


    Set<SecRole> getAuthorities() {
        SecUserSecRole.findAllBySecUser(this)*.secRole
    }

    def beforeInsert() {
        encodePassword()
    }

    def beforeUpdate() {
        if (isDirty('password')) {
            encodePassword()
        }
    }

    protected void encodePassword() {
        password = springSecurityService?.passwordEncoder ? springSecurityService.encodePassword(password) : password
    }

    static transients = ['springSecurityService']

    static constraints = {
        username blank: false, unique: true
        password blank: false

        email(unique: true, blank: false, nullable: true)  // needs to be moved to account
        photo(nullable:true, maxSize: 1024 * 1024 * 2 /* 2MB */)
    }

    static mapping = {
        password column: '`password`'
    }

    String toString() {
        return id + ": " + email + " " + username
    }
}

然后我有一个Spock单元测试:(不是我的所有代码都在这里,但仅仅是我要求提供信息的例子......

@TestFor(User)
class UserSpec extends Specification {
    User user

    def setup() {
        user = new User(
            username: "fredflintstone",
            password: "Wilma1",
            enabled: true).save(failOnError: true, flush: true)

    }

    def cleanup() {
        user = null
    }

    // Constructor tests
    void "test to check constructor works"() {
        when:
        mockForConstraintsTests(User, [user])

        expect:
        user.validate()
        user != null
        user.username != null
        user.password != null
    }

    void "test #hashCode works"() {
        setup:

        mockForConstraintsTests(User, [user])

        expect:
        user.username.hashCode() != null

    }

}

1 个答案:

答案 0 :(得分:5)

第一

你真的不需要(也不应该浪费时间)测试代码,这些代码只有在JVM中的某些东西中断时才会破坏。测试基本的getter和setter对你的代码没有好处,逻辑太简单了。因此,100%的测试覆盖率是一个糟糕的测试目标。你应该瞄准的是......

  1. 可维护的测试
    • 他们可能会在几个月内没有被关注
    • 接触他们的下一位开发者不太可能是你
  2. 所有测试类的一致测试格式
    • 花更多时间理解考试,减少阅读时间
  3. 一种测试格式,可让您一目了然地了解测试覆盖率
    • 当您进行足够的测试
    • 时,您不需要外部工具来告诉您
  4. 100%覆盖类'方法(不包括具有普通逻辑的方法)
  5. 合理完整地覆盖每种方法的输入
    • 每个int参数至少应测试期望值的内外极值,0,负数和正数
    • 理想情况下,如果涉及多个参数,将测试每种可能的测试输入组合
    • 实际上,有足够的空间来调整测试的输入量
  6. 这种方法可能会导致代码覆盖率工具出现一些重叠,但它会更好地响应不断变化的条件,让不熟悉的开发人员在尽可能短的时间内加快速度。

    第二

    由于你是Spock的新手,让我们谈谈它。关于它的最好的事情是参数化测试是多么容易。这是我在单元测试级别测试范围的方法(功能测试并不总是那么简单)。你可能会注意到我在上面概述的测试目标有些重叠。

    • 每个类测试1个Spec Class(在您的情况下为User.class)
    • 每种方法1次测试
      • 每个唯一的非空构造函数都算作方法
    • 1每个可以抛出异常的方法测试
      • 因为异常的测试逻辑通常不能补充正常的测试逻辑
    • 每个输入组合的测试迭代

    这种方法需要健康地了解where:block,但有许多好处。很容易看出哪些方法已经过测试,很容易看出哪些输入已经针对每种方法进行了测试,它极大地鼓励了测试的独立性,它鼓励代码重用,辅助方法重用可以干净利落地跨越多个级别(单一方法)测试,整个Spec Class,多个Spec Classes),以及其他一些我目前无法想到的事情。

    现在进入您的测试用例。如果你的构造函数除了充当巨型setter方法之外什么都不做,你就不应该花太多时间在它上面。一个确保没有发生灾难性事件的测试案例就足够了;我在这里过火了,给你一个如何编写Spock测试的例子。我喜欢地图列表方法,因为它使每个测试迭代紧密耦合,并允许可选变量和其他灵活性。如果您想了解Spock中参数化测试的更多信息,请点击official documentation

    @Unroll(iteration.testName)
    void "testing the constructor"() {
        setup:
            user = new User(
                username: iteration.username,
                password: iteration.password,
                enabled: iteration.enabled).save(failOnError: true, flush: true) 
        when:
            mockForConstraintsTests(User, [user])
    
        expect:
            user != null
            user.validate() == iteration.valid
            user.username == iteration.username
            user.password == iteration.password
            user.enabled == iteration.enabled
            user.username.hashCode() != null // May need modification
    
        where: 
            iteration << [
    
            [testName: "Testing a normal enabled object"
            username: "fredflintstone"
            password: "Wilma1"
            enabled: true,
            valid: true ],
    
            [testName: "Testing a normal disabled object"
            username: "fredflintstone"
            password: "Wilma1"
            enabled: false,
            valid: true ],
    
            [testName: "Testing a disabled user, null name"
            username: null
            password: "Wilma1"
            enabled: false,
            valid: false ],
    
            [testName: "Testing a disabled user, empty name"
            username: ""
            password: "Wilma1"
            enabled: false,
            valid: false ],
            ]
    }
    

    如果hashCode()涉及的不仅仅是一个参数,那么该方法应该可以获得自己的测试,该测试使用Stub来设置测试方法所需的User.class部分。

    个人意见警告!
    与覆盖插件一样有趣,它们分散并掩盖了典型的jUnit单元测试方法所固有的一些主要缺陷。

    如果您有100个测试,每个方法可能有一个输入排列,那么您的100%代码覆盖率是否重要?有点。您有一些证据证明所有内容都已涵盖,但您可能无法将该覆盖范围追溯到任何单个测试。在没有准备好使用它的情况下给你一点理解力。代码覆盖率工具不是。像我上面概述的一个好的测试范围方法可以帮助您从测试指标中获得更多实用性。他们很容易成为不良测试方法的拐杖。