JUnit tests for POJOs

问题:

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 getters and setters? Is it a safe assumption to assume POJOs will work about 100% of the time?

---

Duplicate of - Should @Entity Pojos be tested?

See also

Is it bad practice to run tests on a DB instead of on fake repositories?

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

回答1:

The rule in TDD is "Test everything that could possibly break" Can a getter break? Generally not, so I don't bother to test it. Besides, the code I do test will certainly call the getter so it will be tested.

My personal rule is that I'll write a test for any function that makes a decision, or makes more than a trivial calculation. I won't write a test for i+1, but I probably will for if (i<0)... and definitely will for (-b + Math.sqrt(b*b - 4*a*c))/(2*a).

BTW, the emphasis on POJO has a different reason behind it. We want the vast quantity of our code written into POJOs that don't depend on the environment they run in. For example, it's hard to test servlets, because they depend upon executing within a container. So we want the servlets to call POJOs that don't depend on their environment and are therefore easy to test.

回答2:

POJOs may also contain other functions, such as equals(), hashCode(), compareTo(), and various other functions. It may be useful to know that those functions are working correctly.

回答3:

I don't think there's a point to testing simple property getters and setters. The point of unit-testing is not to verify that your compiler works.

However, as soon as you add a conditional, null-check or other non-trivial behavior to your getters and setters (or other methods) I think it's appropriate to add unit tests.

回答4:

I once spent two hours because of something like this:

int getX()
{
    return (x);
}

int getY()
{
    return (x); // oops
}

Since it takes almost no time to write the tests for simple getters, I do it now out of habit.

回答5:

I use IntelliJ as an IDE, and it pretty much writes trivial POJO's for me - certainly the constructor and getters/settors. I don't see any point in unit testing this since any bugs will more than likely be in the test code I write.

回答6:

My answer is that trivial getters and setters do not merit their own tests. If I add any code other than simple reads or writes, then I add tests.

Of course, this is all boilerplate, so you could easily write a script that generates unit tests for your getters and setters, if you think there's any value there. Certain IDEs may allow you to define a template that creates test cases with test methods filled in for this boilerplate code (I'm thinking of IntelliJ here, but Eclipse can probably handle it too, although I haven't done anything like this in either IDE).

回答7:

In my experience, creating unit tests for POJOs with only getters and setters, is just overkill. There are some exceptions, of course, if there is additional logic in the getter/setter like checking for null and doing something special, than I would create a unit test for that.

Also, if there's a bug in the POJO I'd create a unit test for it so we can prevent it from happening again.

回答8:

It's probably worth a simple test to make sure you've not written

public void setX(int x) {
   x = x;
}

Although you should be coding to avoid that (by putting a final modifier on the method parameter, or similar). It also depends how you're generating your accessors, and if they could suffer from copy/paste errors etc (this will occur even in environments that try to enforce IDE usage - it just will).

My main concern with classes containing lots of setters/getters, however, is what is the class doing ? Objects should do stuff for you, rather than just hold and return data. If these are data entity objects then the setter/getter pattern may be correct. However the better pattern is to set the data in the object, and ask the object to do stuff with it (calculate your bank balance, launch the rocket etc.) rather than return the data and let you do it yourself!

回答9:

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

回答10:

There is a open source utility http://meanbean.sourceforge.net/ that allows you to test POJO's. There is a also a page that describes the merits/questions that one might have on what this utility offers and why it should be used.

I have never tired it myself (yet), but it's been recommend to me.

回答11:

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.

回答12:

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/

回答13:

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>
   

回答14:

This problem can be resolved by using the Lombok library which eliminates all this boilerplate code as well as the equals and hashcode.

So you don't need to test them unless you have a specific requirement for the equals and hashcode

https://projectlombok.org/

回答15:

Unit Test code you want to know works (for the situations tested of course). Don't unit test code you only want to be kind of sure works.

I can't think of much I only want to be kind of sure about.

回答16:

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.