JUnit for getters and setters

As it was highly recommended in one of the books I'm reading I've started to write tests for each of the class I'm creating. I'm not really sure what is a good pract开发者_JAVA技巧ice to cover setters and getters or not. If yes I'm not sure how because to verify the setter method you need to call the getter for this variable and vice versa. So you will never know where the actual problem is. Where I went is just similar tests for setters and getters.

If you practice TDD (Test-Driven Design), the setters and getters will emerge only as you have a need for them - you don't just automatically create them up front "just in case". In this case, the need for the accessor will typically emerge in the course of an already-failing test for a less-rudimentary method. This means that your accessor will be tested, not by a specific test for it, but in the course of testing the broader method. That's better; it's silly to create accessors "just in case," and silly to write tests for methods that are as trivial as that. But it's nice to have them test-covered.

If you care about coverage metrics, setters and getters can kill you.

Regardless of that, you should definitely test them, especially if they do more than set or get.

Also, its OK to test set/get in one test. If the props are private, then you have to do it that way, unless there are side effects of a set. Or you can implicitly test them when testing other methods. For example, if you are testing a DAO, you can use the setters and getters when you write you testSave method...

To make life easier, you might be able to write a reflection based test utility to test setters and getters. Or just write simple tests, its not hard or time consuming, although it is boring...

There are a lot of options here...

If your getters and setters are simply getting and setting a backing variable, then writing unit tests for them does not provide much value as you are essentially testing that the language and compiler are doing what they are supposed to.

Focus instead on testing that behavior works as expected. If you set property A, and that means property B should now have a different value, that might be worth a unit test.

The philosophy of Test Driven Development says "test everything that can possibly break".

Getters and setter are trivial to code and are often generated for you by your IDE. Hopefully the developers of your IDE have already tested that code so you won't have to. The only case i would bother testing getters is if they do more than just set/get.

Write test for your business logic, not tests for the sake of writing tests.

General guideline for writing unit test is if your tested class contains logic.
Even if you have a delegation logic (business layer calls dao layer), I would recommend writing tests for it.

As for value objects (or POJOs to that matter), you can avoid unit testing.

BUT, if you do wish to test those object - use reflection.
You can set a field with reflection and see what the getter returns. You can set the field with a setter and check the value using reflection again.