JUnit tests for POJOs

Question

I work on a project where we have to create unit tests for all of our simple beans (POJOs). Is there any point to creating a unit test for POJOs if all they consist of is gette

Answer 1

I'm experimenting with cobatura for code coverage and just came across the same issue.

It would be nice to have an annotation to add to the class which said don't include this class in code coverage. However it is possible to put your pojo's in a separate package and then exclude that package from the analysis.

See the documentation depending on your tool, it works with Ant, Maven or command line.

Answer 2

MeanBean library provides an API to test POJOs. For example following snippet test whether Emplooyee pojo. Demo Application link.

BeanTester beanTester = new BeanTester();
beanTester.testBean(Employee.class);

Answer 3

IMHO POJOs are automatically tested when logic for any functionality is tested, e.g. For testing any functions, we may need to inject/mock certain values, POJOs, and getter/setter for POJOs are indirectly tested.

However for the specific use-case to eliminate POJOs for unit-testing, it can be achieved following 2 ways:

1. USE LIBRARY: use existing libraries that help test POJOs. One such library I came across is meanbean.

   Ref: http://meanbean.sourceforge.net/

   Maven: http://mvnrepository.com/artifact/org.meanbean/meanbean (current version: 2.0.3)

2. IGNORE POJOs: Sonar can be configured to exclude POJOs or specific packages to be excluded from unit-test coverage reports. Few examples below:

   <properties>
       <sonar.coverage.exclusions>
           **/domain/**/*,
           **/pojos/*
       </sonar.coverage.exclusions>
   </properties>
   

Answer 4

I just started a project to do this. its in pre-alpha stage right now. It is an Eclipse plugin.

While I agree that typically a POJO setter/getter doesn't necessarily need a test, I believe it is nice to have the simple test there because as things change over time, it will make it easier for you to add more tests for the POJO's. The Unit test is set up, the methods are there to test the setter/getter, all you have to do is handle the new complexity.

This also helps with the code-coverage reports, which, helps keep managers happy. (My company uses Emma).

https://sourceforge.net/projects/unittestgplugin/

Answer 5

I think if the getters and setters have been created using an IDE then it should be fine. We have other things to put our code into. Obviously, you would test the POJO's for serialization/de-serialization.

Answer 6

Unit tests not only validate that code works properly, but they document expected behavior. I don't know how many times I've seen things break because some time down the road, someone changes the behavior of a getter or setter in a POJO and then it unexpectedly breaks something else (for example, someone adds logic to the setter that if someone sets a null value on a string, the setter changes it to an empty string so that NPEs don't happen).

I don't look at unit tests on data store POJOs as a waste of time, I see them as a safety net for future maintenance. That being said, if you are manually writing tests to validate these objects, you are doing it the hard way. Take a look at something like http://gtcgroup.com/testutil.html