Do anyone do test cases for pojos?

Question

Is that needed?

Answer 1

Pojos could still contain logic errors.

Answer 2

If it hasn't been tested, it has a bug! ;)

Answer 3

Of course it's needed. All the code that has to work has to be tested.

Answer 4

Of course, what else would you do test cases on?

I like to do Test Driven Development and it is much about testing your pojos (well, actually its about designing your pojos).

Answer 5

Typically. If your model doesn't work as expected, you're going to have a heck of a lot of trouble down the road...

On the bright side, it's a lot easier to test them.

Answer 6

If your PoJos contain logic that's important to your business, then yes, of course test them.

If they don't, then don't bother. Sometimes leaving a class without tests is important since it gives you freedom to refactor it away later.

Answer 7

I write explicit tests for everything except simple getters and setters.

If the getter or setter only contains a return blah; or this.blah = blah; I don't think there is much value. The majority of times these are generated and I feel the time putting the tests together could be better spent elsewhere.

Answer 8

I do except for getters and setters. You have to draw the line somewhere.

Answer 9

Of course, if they contain "mission critical" code, you'll want to test them.

Answer 10

It's easy to say "Of course". Here's the reason why, though: In real software, you have layer upon layer of components. It's easy to say your tiny little pojos at the bottom of the stack are too small to have real errors, but when you experience unexpected results in the software, and you add up all the code involved that has not been thoroughly tested, you end up with a whole Jenga pile of suspects.

However, if you test your lower-level routines before you build higher-level functionality on top of them, when something goes wrong, you know where to look (that is, after re-running the tests on the lower-level routines to make sure something didn't change).

Also keep in mind that it should be relatively easy to write tests for your pojos, because the less functionality a module supplies, the less there is to test.

I do agree about not testing getters and setters.

Answer 11

Typically the POJOs are tested in some context. If you want to perform some logic THAT has to be tested properly (ideally before starting that logic implementation). As for the getters and setters; to test them is usually not necessary as the coverage is obtained by testing the logic:-) Try to check some coverage reporting tools like Cobertura ,Clover or try Emma and see what needs to be tested. I really like Clover reports showing the most dangerous threats in the code.

Answer 12

I think the question is slightly confused as to terminology. A POJO (Plain Old Java Object) refers to a Java object unencumbered by dependencies on particular application servers or third party libraries. Using a good IOC (Inversion Of Control) framework, like Spring, allows you to write all your classes as POJOs so you can test them independently without having to start an app server in your test.

A Java bean is a simple Java class containing private attributes and public getBlah() and setBlah() accessor methods and not much else. Java beans are by nature POJOs.

So if the question was, "Should I test my POJOs (which contain business logic)?" the answer is emphatically yes.

If the question is, "Should I test my Java beans (which are simple value objects with no behaviour)?" the answer is probably not.

Answer 13

No, I don't test POJOs because:

1.- If the POJO contains buseness logic, I extract it from the POJO and, of course, I test it. But that test is already out of the POJO.

2.- If the POJO doesn't containt it, i.e. simple/getters/setters methods, I generate it dynamically, at build-time or at runtime (CGLIB). So I test my code generator, but not my POJOs.

Answer 14

So, as everyone else here has mentioned, yes you need to test them. However, if you have created them because of a design need through TDD, you will find that once you run your code coverage tool, those POJOs (or POCOs for us .net peeps) will in fact, be covered. That is because TDD will only allow you to write/refactor code that driven by some unit test.

This is what makes TDD better than unit testing, IMHO.