Is it necessary to cover POJO by tests according to TDD?

Question

I am currently reading Uncle Bob's books, trying to embrace TDD in my professional life. At the moment I am in doubt about whether it is necessary to write tests like that:

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");
}

What are pros and cons of such approach?

Testing getters and setters is a good idea. If you're paid by the hour and nobody follows what you spend your time on. — Kayaman, Oct 01 '19 at 13:56
@T.J. Crowder, I've edited the post to make it more concrete — Aleksandr Semyannikov, Oct 01 '19 at 14:00
if you cover the other code (repositories, controllers, services, etc), that should include most or all of the pojo methods. Use a code coverage tool to verify what is covered. — Nathan Hughes, Oct 01 '19 at 14:04
I'm not familiar with the state of the art in Java testing toolkits. Is it really the case that tools don't cater specifically for this? E.g., you can't just slap a `@TestPOJO` annotation on the class and have the testing framework A) Test that the getters and setters work, B) Test that the constructors work, C) Check that the object doesn't provide any non-POJO methods? — T.J. Crowder, Oct 01 '19 at 14:26
At the risk of stating the obvious (hence commenting, doesn't seem worthy of an answer): Pros: * Ensures that `Person` is written to correctly implement its POJO contact in the first place (e.g., the setters really set their respective private fields, the getters really get their respective private fields). * Ensures that if `Person` is modified at some point in the future such that its fundamental POJO contract is broken, your tests start failing. Con: * More tests. — T.J. Crowder, Oct 01 '19 at 14:26
I've found that writing tests at such a low level of abstraction can cause coupling between the tests and the implementation. Usually the test I'll write will be much higher up the abstraction chain, and the needed methods on your object will have to be written to get that test to pass. This way refactoring becomes easier and doesn't break a bunch of tests. — Kraylog, Oct 02 '19 at 13:04

Nathan Hughes · Answer 1 · 2019-10-01T14:41:03.097

1

First, when writing tests use a code coverage tool to verify what gets covered.

When you write tests for the code that uses the pojos, that should cover the pojo getters and setters as well. That is more valuable than tests that only exercise the pojos, because it shows that the pojos function in the context of the application code.

If I add methods besides getters and setters to the pojos, I add tests for those. But I try to avoid tests of getters and setters.

There are test frameworks for this (see this question) that are useful for checking equals and hashcode too.

edited Oct 01 '19 at 14:41

answered Oct 01 '19 at 14:23

Nathan Hughes

94,330
19
181
276

Thank you, I appreciate all your comments in this topic, could you please edit your answer a little to make it pertinent to the question about pros and cons and I could mark it as the right answer? – Aleksandr Semyannikov Oct 01 '19 at 14:45

score 1 · Accepted Answer · answered Oct 02 '19 at 00:29

Is it necessary to cover POJO by tests according to TDD?

In Test Driven Development by Example, Kent Beck wrote that TDD is defined by two rules

Don’t write a line of new code unless you first have a failing automated test.
Eliminate duplication.

If you accept that Kent Beck's writing circa 2002 is authoritative, then yes - you must write an automated test before you write a line of your new POJO.

In 2008, an expert wrote

I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence

My interpretation is that it isn't TDD if you are not starting with an automated test -- but TDD is not the right tool for all circumstances.

Horses for courses.

Ori Marko · Answer 3 · 2019-10-01T15:57:18.970

0

If you use auto generated getters and setters framework ,as Lombok, you will not need to do test it

@Getter
@Setter
public class Person {

edited Oct 01 '19 at 15:57

answered Oct 01 '19 at 13:59

Ori Marko

56,308
23
131
233

Thanks for your answer, I edited my question a little to make it a bit more concrete. Anyway, what are pros and cons of such approach if you can't use things like Lombok? – Aleksandr Semyannikov Oct 01 '19 at 14:03
1

Do you mean "code coverage tools won't complain about it"? Because Lombok brings nothing more than let's say IDEA's autogenerate getters/setters. It's hardly Lombok's special feature. – Kayaman Oct 01 '19 at 14:05
lombok can cause code coverage problems when it creates constructors that may not be used. if you want builders generated for you then it requires all-arg constructors. Code coverage tools will still complain about generated code. the best thing about generated code is you know there won't be anything strange like you might find in handwritten code, so that would make testing less of an issue. – Nathan Hughes Oct 01 '19 at 14:10
@nathanhughes updated to use `@Getter @Setter` ehich doesn't create constructors – Ori Marko Oct 01 '19 at 15:58
@Kayaman I mean not need to tedt auto generated setters – Ori Marko Oct 01 '19 at 15:59
@AleksandrSemyannikov If you can't, theoretically you need to test, but as others suggest, check using code coverage which methods aren't tested – Ori Marko Oct 01 '19 at 16:03

Is it necessary to cover POJO by tests according to TDD?

3 Answers3