在测试中构造对象通常是一件艰苦的工作,通常会产生大量可重复且难以阅读的代码。 有两种用于处理复杂测试数据的常见解决方案: 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