Why we need test cases to run against plain POJOs

Question

While writing junit tests, I cannot help but think that junit tests are suitable for classes with methods that perform a lot of business logic. That way you write test conditions to test each if-else block.

But in an enterprise application that has got a lot of java beans, why does junit need to run against those? It seems redundant to write a test case for a standard getter/setter that does not perform any logic or computation.

Should junit not be only for classes with business logic and not plain POJOs?

Answer 1

POJO doesn't mean "class with no business logic", it means the class doesn't have dependencies on infrastructure or on a framework. (Some frameworks that use POJOs, like Hibernate and Spring, encourage their users to make their POJOs conform to some of the JavaBean conventions, mostly naming of getters and setters.) Services in Spring are POJOs (or close to being POJOs, some people might think the introduction of annotations was a step away from POJO purity), and they have business logic.

If a class doesn't contain any logic there is no value testing it. Typically those kinds of classes get covered by tests that exercise the real functionality, since they are used to hold data passed into or out of the business logic code.

If you really have to write tests for classes with only getters and setters, consider writing some code to generate these useless tests for you.

Answer 2

FYI, I have created a framework posted on GitHub for automatically testing getters / setters.

It works in two ways, you can either call a method to test a specific field either with a default set of values or with your own. Or you can pass a call and have the framework test all fields that were found via reflection.

GetterSetterTester tests single fields.

ReflectionGetterSetterTester test all fields in a class.