Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
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?
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 forif (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.