Should domain objects and simple JavaBeans be unit tested?

Question

Should simple JavaBeans that have only simple getters and setters be unit tested??

What about Beans with some logic in getters and setters?

Answer 1

If it's not worth testing, it's not worth writing.

That doesn't always mean you should write tests. Sometimes it means you should delete code. Do you need these beans? Do they actually do anything important? If you need them, you should write tests. If not, delete the code and live a happier life knowing you have less to maintain.

Answer 2

You only have to test the stuff that you want to work correctly.

(Sorry to whoever I stole that quote from)

Answer 3

Check out this another question: http://stackoverflow.com/questions/89620/do-anyone-do-test-cases-for-pojos#90691

Answer 4

I think that is one of those questions that everybody asks to himself (herself).

But consider this: the inner logic of the accessors is dead simple now, but it may change in the future, and - which is far more important - you will feel free to change it to whatever you want if you have tests for the methods. So, you get freedom and confidence by means of couple of testcases. Sounds like a good deal, huh?

Answer 5

if it's just a getter/setter without changing anything to the values, I'd say there's no need for testing. If it does do some logic, a few simple unit tests will provide some security.

Answer 6

How can you securely refactoring untested code? What will happen when your bean pojo changes if you haven't tests? Are you creating a Anemic Domain Model?

Kind Regards

Answer 7

You should test things that have some meaning. Getters and setters commonly do not contain any logic and are just used in Java for the lack of properties. I think that testing them is just as stupid as checking that Java does return a value every time you evaluate "a.x".

If the accessor does have logic it's up to you to decide the threshhold. If your team is lazish. it's best to test all logic. If it is more disciplined, it's better to find a ratio that doesn't make you write too much boilerplate tests.

Answer 8

You should not write tests which:

• Test the language or the IDE (i.e. automatically generated getters and setters)
• Add no value to your test harness and kill your enthusiasm for Unit Testing

The same applies for .NET objects which only have properties (sometimes called 'Info' objects).

In an ideal world you would have 100% test coverage, but in practice this is not going to happen. So spend the client's money where it will add the most benefit i.e. writing tests for classes with complex state and behaviour.

If your JavaBean becomes more interesting you can of course add a test case later. One of the common problems associated with Unit Testing / TDD is the mistaken belief that everything has to be perfect first time.

Answer 9

Like Maxim already said: having tests will not add extra functionality to your application, but will enable you to make changes with more confidence. To determine which classes/methods chould be unit tested, I always ask myself two questions:

• is this piece of code imported in relation to the overall functionality?
• will this piece of code probably change over the lifetime of this applicaiton?

If both questions are answered with yes, a unit test is necessary.

Answer 10

In my opinion, the purpose of writing unit test is testing the business logic of the unit in test. Therefore, if there is no business logic (for example, when a getter simply returns a value or a setter sets it) then there is no point in writing a test. If, however, there is some logic (getter changes the data in some way before returning it) then yes, you should have a unit test. As a general rule, I believe one should not write tests for beans that do not contain any business logic.

Answer 11

If it has an external interface and contains code that a person wrote (as opposed to being auto-generated by the IDE or compiler), then it should definitely be tested.

If one or both of those conditions doesn't hold, then it's something of a grey area and comes down to more of a "belt and suspenders"-type question of just how careful you feel the need to be.

Answer 12

Another rule of thumb (similar to what others have said) is "test anything that could possibly break". To me that excludes auto-generated getter and setters, but includes hand-written ones that contain some logic.