Link Details

nice idea, however that means that tests are not good. When you have good tests you dont care about that.
for example:

Cat cat = house.findCat(House.KITCHEN);
assertEquals(cat.getName(),"Garfield");

cat.setName("Garfield");
house.saveCat(cat);
// save check

checking for setters/getters is not needed in that example.

Your getters and setters should be covered by calling the code that uses them. Thats where you will end up find the real bugs that they could be involved in. And if you don't have any code which uses them, that should raise a red flag (in fact, thats the real value I've seen in looking at code coverage, you often find unreachable or useless code that should be removed).

100% targetted test coverage considered pointless.
As @nick says, above, If your tests aren't running through them, and retrieving the data without specifically testing a completely trivial function, then you have bigger problems.

Great! Will use it for my Unit Tests

I like the idea but I modified it to take advantage of the Jakarta BeanUtils

public static void executeGetterSetterTest(Object bean) throws Exception {

        PropertyDescriptor[] propertyDescriptors = PropertyUtils.getPropertyDescriptors(bean);

        for (int i = 0; i < propertyDescriptors.length; i++) {

            PropertyDescriptor propertyDescriptor = propertyDescriptors[i];

            String name = propertyDescriptor.getName();

            if (PropertyUtils.isWriteable(bean, name)) {

                Object testValue = getTestValue(PropertyUtils.getPropertyType(bean, name));

                BeanUtils.setProperty(bean, name, testValue);

                Object property = propertyDescriptor.getReadMethod().invoke(bean, new Object[0]);

                Assert.assertEquals("Property '" + name + "' failed.", testValue, property);

            }

        }

    }

Please don't do stuff like:

"is" + method.getName().substring(3)

Have a look at the javabean packages:

java.beans.BeanInfo;
java.beans.IntrospectionException;
java.beans.Introspector;
java.beans.PropertyDescriptor;

You also completely 'forgot' te mention that if encapsulation is done right returned mutable objects shouldn't mutate their parent object... getters and setters are more complex then they seem at first sight!

The raised issues seem to me:
* "the setters and getters should be tested indirectly by code that uses your model class" - I think that the purpose of a unit test is that you test a unit in isolation, and you should not rely on other scattered unit tests.
* "x% targetted test coverage considered pointless." - I think so too, and unfortunately the company I work at does not agree and wants a coverage of 75%. Actually, we have this coverage tool and you have to set a standard somehow - without this number we would only have a vague requirement, which nobody would use. Now, we have a simple requirement and with some creativity also the means to achieve that goal.

In the article http://www.dzone.com/links/rss/getters_setters_and_the_great_coverage_conspiracy.html the author argues:
* "your code may have too many setters/getters" - I also think that classes with only setters and getters are just simple data structures that should be avoided, however, in practice I use EJB's, JSF and other frameworks that rely on the Java bean concept with setters and getters.
* "some people may test only the easy stuff and avoid the difficult code to achieve an easy code coverage percentage" - I absolutely agree, the goal of unit testing is ensuring quality, the percentage number is just an indication of that, not a replacement.,The raised issues seem to me:
* "the setters and getters should be tested indirectly by code that uses your model class" - I think that the purpose of a unit test is that you test a unit in isolation, and you should not rely on other scattered unit tests.
* "x% targetted test coverage considered pointless." - I think so too, and unfortunately the company I work at does not agree and wants a coverage of 75%. Actually, we have this coverage tool and you have to set a standard somehow - without this number we would only have a vague requirement, which nobody would use. Now, we have a simple requirement and with some creativity also the means to achieve that goal.