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 practice 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.
+1
A:
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.
RyanHennig
2010-10-26 18:39:20
A:
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...
hvgotcodes
2010-10-26 18:39:49
Testing just to achieve high coverage metrics is sort of like getting paid per line of code.. imho...
Alexander Sagen
2010-10-26 18:51:05
@alexander I didnt say you should test for metrics. I said setters/getters can kill metrics. Ill clarify above.
hvgotcodes
2010-10-26 18:52:18
A:
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.
Bivas
2010-10-26 18:44:00
A:
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.
willcodejavaforfood
2010-10-26 18:44:32
...and if they "do more than just set/get", they're not really setters/getters in the strictest sense. It's easier to work with code where only raw accessors have those names; you can look at the name and know, "this does nothing more than set/get".
Carl Manaster
2010-10-26 18:46:53
+1
A:
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.
Carl Manaster
2010-10-26 18:45:15