是否有必要根据TDD通过测试覆盖POJO？ [关闭]

Question

我目前正在阅读 Bob 叔叔的书，试图在我的职业生涯中拥抱 TDD。目前我怀疑是否有必要编写这样的测试：

public class Person {
    private String firstName;
    private String middleName;
    private String lastName;

    /*getters and setters*/
}

@Test
public void testPersonCreation() {
    Person person = new Person();

    person.setFirstName("Robert");
    person.setMiddleName("Cecil");
    person.setLastName("Martin");

    Assertions.assertThat(person.getFirstName()).isEqualTo("Robert");
    Assertions.assertThat(person.getMiddleName()).isEqualTo("Cecil");
    Assertions.assertThat(person.getLastName()).isEqualTo("Martin");
}

这种方法的优缺点是什么？

Answer 1

是否需要按照TDD通过测试覆盖POJO？

在Test Driven Development by Example 中，Kent Beck 写道，TDD 由两个规则定义

• 除非您首先有一个失败的自动化测试，否则不要编写一行新代码。
• 消除重复。

如果您接受 Kent Beck 大约 2002 年的著作是权威的，那么是的 - 您必须在编写一行新 POJO 之前编写一个自动化测试。

2008年，an expert wrote

我是通过有效的代码而不是测试获得报酬，所以我的理念是尽可能少地测试以达到给定的信心水平

我的解释是，如果您不从自动化测试开始，它就不是 TDD ——但 TDD 并不是适用于所有情况的正确工具。

课程用马。

Answer 2

首先，在编写测试时使用代码覆盖工具来验证覆盖了什么。

当您为使用 pojo 的代码编写测试时，也应该涵盖 pojo getter 和 setter。这比只使用 pojos 的测试更有价值，因为它表明 pojos 在应用程序代码的上下文中起作用。

如果我向 pojo 添加 getter 和 setter 之外的方法，我会为这些添加测试。但我尽量避免对 getter 和 setter 进行测试。

对此有一些测试框架（请参阅this question），它们也可用于检查等号和哈希码。

Answer 3

如果您使用自动生成的 getter 和 setter 框架，如 Lombok，则无需对其进行测试

@Getter
@Setter
public class Person {