如何在 Spock 单元测试中以 100% 的代码覆盖率测试 Groovy 构造函数

我的问题是：我是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
    }
}

First

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

可维护的测试
- 他们可能会几个月不被人看
- 下一个接触它们的开发人员不太可能是你
所有测试类的一致测试格式
- 花更多的时间理解测试，花更少的时间"阅读"它
一种测试格式，可让您一目了然地了解测试覆盖率
- 不需要一个外部工具来告诉你什么时候你已经测试了足够多
100%覆盖类方法(不包括具有平凡逻辑的方法(
合理完整地覆盖每种方法的输入
- 每个 int 参数至少应测试期望值的内极值和外极值，0、负数和正数
- 理想情况下，如果涉及多个参数，将测试可能的测试输入的每个组合
- 实际上，有足够的空间来削减用于测试的输入量

这种方法可能会导致代码覆盖率工具眼中的一些重叠，但它可以更好地响应不断变化的条件，并使不熟悉的开发人员在尽可能短的时间内跟上进度。

第二

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

每个类测试 1 个规格类(用户.class在您的情况下(
每种方法1次测试
- 每个唯一的非空构造函数计为一个方法
每个可能引发异常的方法 1 个测试
- 因为异常的测试逻辑通常不能补充正常的测试逻辑
每个输入组合 1 次测试迭代

这种方法需要对 where：块有一个健康的理解，但有很多好处。很容易看到哪些方法已经测试过，很容易看到每个方法的输入已经测试过，它极大地鼓励了测试独立性，它鼓励代码重用，帮助程序方法重用可以干净且可预测地跨多个级别(单个方法的测试、整个规范类、多个规范类(的范围，以及一些我目前无法想到的其他事情。

现在进入您的测试用例。如果你的构造函数除了充当一个巨大的二传手方法之外什么都不做，你不应该花太多时间在上面。一个测试用例来确保没有灾难性的事情发生就足够了;我在这里过分地举了一个例子，说明我是如何编写 Spock 测试的。我喜欢映射列表方法，因为它使每个测试迭代紧密耦合，并允许可选变量和其他灵活性。如果您想了解有关 Spock 中的参数化测试的更多信息，这里是官方文档。

@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% 代码覆盖率分数是否重要？有点。您有一定程度的证据证明所有内容都被覆盖，但您可能无法将覆盖范围追溯到任何单个测试。给你一个小程度的理解，但没有能力准备好使用它。代码覆盖率工具还不错。像我上面概述的那样，一个好的测试范围方法可以帮助你从测试指标中获得更多实用性。它们很容易成为糟糕的测试方法的拐杖。

First

第二

相关内容

最新更新

热门标签：