3 ms·
The only problem with not writing tests for getters/setters is that is makes it harder to identify actual code that is untested. If code coverage tools were sma
by jeffskj 15y ago
The only problem with not writing tests for getters/setters is that is makes it harder to identify actual code that is untested. If code coverage tools were smarter about not counting getters/setters towards the coverage number it wouldn't be a problem but if they aren't tested your coverage report might say you have 25% coverage in a package and you don't know that's because it has a bunch of DTOs in it or if its because there's bunch of actual untested logic in that package. The way we solved that problem on my team was to write a little utility that used reflection to automatically test the basic getter/setter pairs which made writing the tests for DTOs basically one line of code.
- astral303 15y agoMany coverage tools have ways to ignore getters/setters and things like "if (debug logging enabled) log" types of statements.
- jeffskj 15y agoI'm not aware of any open source ones for Java that can do that, Atlassian Clover (not open source) might do it but I'm not sure on that. If you know of one I'd love to take a look at it.
- reiz 15y agoI think the same. And I think getters and setters are useless! Just wasted lines of code. One more reason to switch to a dynamic language like Ruby or Python. The applications I saw in the last 14 months in the Ruby community are much more object oriented than the stuff I saw the last 10 years in the Java World. And because they are more object oriented their are much more easy to test. It is so easy to write test cases for a Ruby on Rails App, but it is a nightmare to do the same for JSF & EJB.