Java 实体类及其单元测试的良好实践

Question

我只想确认你们是否认为这是一个好习惯：使用 javax.validation.constraints 注释用一些验证在 java 中编写实体类编写单元测试以断言验证编写单元测试来断言 getter 和 setter，因为这是一种断言该类包含我们需要的所有字段的方法@Builder@AllArgsConstructor@NoArgsConstructor@EqualsAndHashCode(callSuper = true)@ToString(exclude = "client")@Data@Entity@Table(name = "addresses")public class Address extends BaseEntity {  private static final long serialVersionUID = -5966581124342250987L;  @NotNull  @Size(min = 2, max = 40)  @Column(name = "line1", nullable = false, length = 40)  private String line1;  @Size(min = 2, max = 40)  @Column(name = "line2", length = 40)  private String line2;  @NotNull  @Size(min = 2, max = 40)  @Column(name = "city", length = 40)  private String city;  @NotNull  @Size(min = 2, max = 2)  @Column(name = "country_code", length = 2)  private String countryCode; //code ISO 3166 two-letter country codes  @NotNull  @EqualsAndHashCode.Exclude  @ManyToOne(fetch = FetchType.LAZY)  @JoinColumn(name = "client_id")  private Client client;}

Answer 1

实体只是没有逻辑的 POJO 对象。了解您究竟测试了什么是值得的。

如果你想测试实体验证器，那么放置一些随机数据而不是预定义的数据是值得的

不但是private static final String ADDRESS_LINE1 = "Address line 1";_

 Address address = Address.builder()
            .line1( randomAddress() )
            .city( randomCity() )
            .countryCode( randomCountry() )
            .build()

random*()返回一些有效返回值的预定义方法在哪里。

如果你想测试Hibernate和mappers，值得考虑一些像H2这样的嵌入式数据库来做测试。

关于 getter 和 setter，大多数时候它们是自动生成的，这就是为什么我看不到测试它们的意义。

Answer 2

实体是数据库的增强镜像（实例是 SSOT，类是 SVOT），M im MVC，它们是 beans。Bean 是否应该进行单元测试：否。

你所做的是在实体中混合 M 和 C。C应该进行单元测试吗？Yes!!!.

所以你真的应该测试它们！

Answer 3

请注意，实际上您只测试了所用内容的一小部分：例如，所有和无参数构造函数、setterhashCode()都equals()没有经过测试。

现在测试它是一个好习惯吗？我认为是的。
使用 Lombok 注释生成一些实现，您只能在运行时（测试和应用程序运行时）验证行为。
例如，注释可能不会产生预期的行为，因为与另一个注释冲突或使用不当（例如，如果生成的方法中存在循环，则会出现 stackoverflow 错误），您可能只会在运行时发现这些行为，充其量只能清楚地说明异常问题或最坏的情况是根本原因不明显的潜在错误。
同样，如果有人通过替换它（出于调试目的）而无意中破坏了实现：

@ToString(exclude = "client")

经过 ：

@ToString

您希望自动测试检测到它。
最后，如果您出于任何原因想要删除项目的 Lombok，您希望进行回归测试，以断言没有 Lombok 的新实现仍然是正确的。
所以是的，使用许多注释意味着编写许多断言/测试。
但在某种程度上这是正常的，因为第三方 API 为您的类提供动力并不是一个细节。
请注意，对于 getter/setter，我认为测试它们不会带来很大的价值，因为能够调用它们通常意味着它们已由 Lombok 正确实现。

用这些术语进行推理（统一测试您的类 API 提供的内容）有利于生成有用且高质量的代码，因为我们在添加生成某些代码/逻辑的注释之前会三思而后行。这是一件好事，因为我经常看到滥用 Lombok 注释：“我们不确定是否需要它，但没问题，因为它很容易声明”。

我将对注释应用完全相同的想法， javax.validation.constraints而对于验证问题，我可能会使用参数化测试来减少样板代码。