Is there a Java unit-test framework that auto-tests getters and setters?

Question

There is a well-known debate in Java (and other communities, I'm sure) whether or not trivial getter/setter methods should be tested. Usually, this is with respect to code coverage. Let's agree that this is an open debate, and not try to answer it here.

There have been several blog posts on using Java reflection to auto-test such methods.

Does any framework (e.g. jUnit) provide such a feature? e.g. An annotation that says "this test T should auto-test all the getters/setters on class C, because I assert that they are standard".

It seems to me that it would add value, and if it were configurable, the 'debate' would be left as an option to the user.

Answer 1

I created the OpenPojo project for solving this exact problem.

The project allows you to validate:

• Enforce Pojo coding standard (i.e. All fields private, or no native variables, ...etc)
• Enforce Pojo behaviour (i.e. setter does JUST setting, no transformation, etc)
• Validate Pojo Identity (i.e. Use annotation based equality & hashcode generation)

See Tutorial

Answer 2

I'm not aware of any readily available library or class that does this. This may mainly be because I don't care as I am on the side of strongly opposing such tests. So even though you asked there must be a bit of justification for this view:

I doubt that autotesting getters and setters benefit your code quality or your coverage: Either these methods are used from other code (and tested there, e.g. 100% covered) or not used at all (and could be removed). In the end you'll leave getters and setters in because they are used from the test but nowhere else in the application.

It should be easy to write such a test, e.g. with Apache Commons BeanUtils, but I doubt you really need it if you have good tests otherwise.

Answer 3

Unitils does this w/ the static method assertRefEquals.

Answer 4

In the most cases setter and getter do more as only setting and getting an internal field. An Object has to check internal rules that it hold only valid values. For example

• are null values possible?
• are empty strings possible?
• or negative values?
• or a zero value?
• or values from a list are valid?
• or is there a maximal value?
• or is there a maximum precision on BigDecimal values?

The unit test should check if the behavior correct if there invalid values. This can not be automated.

If you have no logic on the setter and getter then it must be used anywhere in your application. Write a test where your object is a parameter for a more complex test. You can test it then with different values from the list.

Test your business logic and not the getter and setter. The result should also a coverage of the getter and setter. The methods should be any result in your business logic also if you have only a public library. If the getter and setter have no code coverage then removed it.

Answer 5

I've done something like that. A simple java class that takes an object and test all the getters and setter methods. http://sourceforge.net/projects/getterandsetter/

I do think you should avoid getter and setter methods as much as possible, but as long as they're around and it takes two lines to test them, it's a good thing to do it.

Answer 6

I'll favor OO design over code coverage, and see if I cannot move those fields to the class that needs them. So I would try to see if those getters and setters can be removed, as suggested before. getters and setters are breaking encapsulation.

Answer 7

I am trying out openpojo

I have kicked the tires and it seems to do the job.

1. It allows you to check all the pojo's in your project.
2. It seems to check the best practices on pojo's

Check this tutorial for a quick start Tutorial

Answer 8

I guess this library is the answer to your question

it tests all the bean's initial values, the setters, the getters, hashCode(), equals() and toString(). All you have to do is define a map of default and non default property/value.

It can also test objects that are beans with additional non default constructors.

Answer 9

Answering the previous comment at @me here because of my reputation:

Vlookward, not writing getters/setters makes no sense at all. The only options for setting private fields is to have explicit setters, to set them in your constructor, or to set the indirectly via other methods (functionally deferring the setter to another place). Why not use setters?

Well, sometimes, there is no need to the field be private (Sorry if my English is not very good). Often, we write our software as it was a library and we encapsulate our fields (our business logic fields) with unnecessary getters/setters.

Other times, that methods are actually necessary. Then, there are two possibilities:
1. There is business logic inside them. Then they sould be tested, but they aren't real getters/setters. I always write that logic in other classes. And the tests test that other classes, not the POJO.
2. There is not. Then, do not write them by hand, if you can. For example, an implementation for the next interface may be fully autogenerated (and also in runtime!) :

interface NamedAndObservable {
  String getName();
  void setName(String name);
  void addPropertyChangeListener(PropertyChangeListener listener);
  void addPropertyChangeListener(String propertyName,
                                 PropertyChangeListener listener);
}

So test only what is written by hand. No matter if it is a getter/setter.

Answer 10

I don't write test cases for each property, but instead test all of the setters/getters in a single test case using reflection/introspector to determine the type(s). Here is a great resource that shows this:

http://www.nearinfinity.com/blogs/scott_leberknight/do_you_unit_test_getters.html