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

首先，在编写测试时，使用代码覆盖率工具来验证所涉及的内容。

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

如果我将除getter和setter之外的方法添加到pojo中，则将为它们添加测试。但是我尽量避免对吸气剂和吸气剂进行测试。

为此有一些测试框架（请参见this question），它们对于检查均值和哈希码也很有用。

Answer 2

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

在Test Driven Development by Example中，肯特·贝克（Kent Beck）写道，TDD由两个规则定义

除非您首先没有通过自动测试，否则不要编写任何新代码。
消除重复。

如果您接受肯特·贝克（Kent Beck）大约在2002年的著作是权威的，那么可以-在编写一行新的POJO之前，您必须编写一个自动测试。

2008年，an expert wrote

我从有效的代码而不是测试中获得报酬，所以我的理念是尽可能少地测试以达到给定的置信度

我的解释是，如果您不进行自动化测试，那不是TDD，但TDD并非在所有情况下都是正确的工具。

课程的马匹。

Answer 3

如果您使用自动生成的getter和setters框架（如Lombok），则无需进行测试

@Getter
@Setter
public class Person {

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

3 个答案: