测试数据构建器和对象母亲：另一种眼神

在测试中构造对象通常是一件艰苦的工作，通常会产生大量可重复且难以阅读的代码。 有两种用于处理复杂测试数据的常见解决方案： Object Mother和Test Data Builder 。 两者都有优点和缺点，但是（巧妙地）结合可以为您的测试带来新的质量。

注意：关于Object Mother和Test Data Builder ，已经有很多文章可以找到，因此我将使我的描述非常简洁。

对象母亲

不久，“ 对象母亲”是一组工厂方法，允许我们在测试中创建类似的对象：

// Object Mother
public class TestUsers {

    public static User aRegularUser() {
        return new User("John Smith", "jsmith", "42xcc", "ROLE_USER");
    }

    // other factory methods

}

// arrange
User user = TestUsers.aRegularUser();
User adminUser = TestUsers.anAdmin();

每次需要数据变化稍有不同的用户时，都会创建新的工厂方法，这会使“ Object Mother随时间增长。 这是Object Mother的缺点之一。 可以通过引入Test Data Builder解决此问题。

测试数据生成器

Test Data Builder使用Builder模式在单元测试中创建对象。 一的简短提醒Builder ：

构建器模式是对象创建软件设计模式。 […]构建器模式的目的是找到可伸缩构造函数反模式的解决方案。

让我们看一下Test Data Builder的示例：

public class UserBuilder {

    public static final String DEFAULT_NAME = "John Smith";
    public static final String DEFAULT_ROLE = "ROLE_USER";
    public static final String DEFAULT_PASSWORD = "42";

    private String username;
    private String password = DEFAULT_PASSWORD;
    private String role = DEFAULT_ROLE;
    private String name = DEFAULT_NAME;

    private UserBuilder() {
    }

    public static UserBuilder aUser() {
        return new UserBuilder();
    }

    public UserBuilder withName(String name) {
        this.name = name;
        return this;
    }

    public UserBuilder withUsername(String username) {
        this.username = username;
        return this;
    }

    public UserBuilder withPassword(String password) {
        this.password = password;
        return this;
    }

    public UserBuilder withNoPassword() {
        this.password = null;
        return this;
    }

    public UserBuilder inUserRole() {
        this.role = "ROLE_USER";
        return this;
    }

    public UserBuilder inAdminRole() {
        this.role = "ROLE_ADMIN";
        return this;
    }

    public UserBuilder inRole(String role) {
        this.role = role;
        return this;
    }

    public UserBuilder but() {
        return UserBuilder
                .aUser()
                .inRole(role)
                .withName(name)
                .withPassword(password)
                .withUsername(username);
    }

    public User build() {
        return new User(name, username, password, role);
    }
}

在我们的测试中，我们可以如下使用构建器：

UserBuilder userBuilder = UserBuilder.aUser()
    .withName("John Smith")
    .withUsername("jsmith");

User user = userBuilder.build();
User admin = userBuilder.but()
    .withNoPassword().inAdminRole();

上面的代码看起来非常不错。 我们有一个流畅的API，可以提高测试代码的可读性，并且可以肯定地消除了使用Object Mother需要多种工厂方法来处理测试中需要的对象变化的问题。

请注意，我添加了一些默认属性值，这些默认值可能与大多数测试无关。 但是，由于我们将它们定义为公共常量，因此可以在断言中使用它们。

注意：本文使用的示例相对简单。 它用于可视化解决方案。

对象母亲和测试数据生成器结合

两种解决方案都不完美。 但是，如果我们将它们结合起来呢？ 想象一下， Object Mother返回一个Test Data Builder 。 有了这个，您就可以在调用终端操作之前操纵构建器状态。 这是一种模板。

看下面的例子：

public final class TestUsers {

    public static UserBuilder aDefaultUser() {
        return UserBuilder.aUser()
                .inUserRole()
                .withName("John Smith")
                .withUsername("jsmith");
    }

    public static UserBuilder aUserWithNoPassword() {
        return UserBuilder.aUser()
                .inUserRole()
                .withName("John Smith")
                .withUsername("jsmith")
                .withNoPassword();
    }

    public static UserBuilder anAdmin() {
        return UserBuilder.aUser()
                .inAdminRole()
                .withName("Chris Choke")
                .withUsername("cchoke")
                .withPassword("66abc");
    }
}

现在， TestUsers提供了用于在我们的测试中创建类似测试数据的工厂方法。 它返回一个构建器实例，因此我们能够根据需要在测试中快速而完美地修改对象：

UserBuilder user = TestUsers.aUser();
User admin = user.but().withNoPassword().build();

好处是巨大的。 我们有一个用于创建相似对象的模板，如果我们需要在使用返回对象之前修改返回对象的状态，则我们拥有构建器的强大功能。

丰富测试数据生成器

考虑以上内容时，我不确定是否真的需要单独的Object Mother 。 我们可以轻松地将方法从Object Mother直接移动到Test Data Builder ：

public class UserBuilder {

    public static final String DEFAULT_NAME = "John Smith";
    public static final String DEFAULT_ROLE = "ROLE_USER";
    public static final String DEFAULT_PASSWORD = "42";

    // field declarations omitted for readability

    private UserBuilder() {}

    public static UserBuilder aUser() {
        return new UserBuilder();
    }

    public static UserBuilder aDefaultUser() {
        return UserBuilder.aUser()
                .withUsername("jsmith");
    }

    public static UserBuilder aUserWithNoPassword() {
        return UserBuilder.aDefaultUser()
                .withNoPassword();
    }

    public static UserBuilder anAdmin() {
        return UserBuilder.aUser()
                .inAdminRole();
    }

    // remaining methods omitted for readability

}

因此，我们可以在单个类中维护User数据的创建。

请注意，在此Test Data Builder是一个测试代码。 如果我们在生产代码中已经有一个生成器，那么创建一个Object Mother返回一个Builder实例听起来是一个更好的解决方案。

可变对象呢？

当涉及可变对象时， Test Data Builder方法可能存在一些缺点。 在许多应用程序中，我主要处理可变对象（又称为beans或anemic data model ），也许你们中的许多人也这样做。

从理论上讲， Builder模式用于创建不变的价值对象。 通常，如果我们处理可变对象，乍一看， Test Data Builder可能看起来像是重复的：

// Mutable class with setters and getters
class User {
    private String name;
    public String getName() { ... }
    public String setName(String name) { ... }

    // ...
}

public class UserBuilder {
    private User user = new User();

    public UserBuilder withName(String name) {
        user.setName(name);
        return this;
    }

    // other methods

    public User build() {
        return user;
    }
}

在测试中，我们可以创建一个如下用户：

User aUser = UserBuiler.aUser()
    .withName("John")
    .withPassword("42abc")
    .build();

代替：

User aUser = new User();
aUser.setName("John");
aUser.setPassword("42abc");

在这种情况下，创建Test Data Builder是一个折衷方案 。 它需要编写更多需要维护的代码。 另一方面，可读性大大提高。

摘要

在单元测试中管理测试数据并非易事。 如果找不到合适的解决方案，那么最终将获得大量难以理解和维护的样板代码。 另一方面，没有解决该问题的灵丹妙药。 我尝试了许多方法。 根据问题的大小，我需要选择一种不同的方法，有时在一个项目中结合使用多种方法。

您如何处理测试中的数据构建？

资源资源

• Petri Kainulainen： 编写干净的测试–被认为有害的新方法
• Growing Object-Oriented Software, Guided by Tests –第22章： Constructing Complex Test Data 。

翻译自: https://www.javacodegeeks.com/2014/06/test-data-builders-and-object-mother-another-look.html