4

I have recently tried to to implement unit tests on a Java Web Application my project is built on MVC design architecture and uses Spring & JPA Hibernate and JSF here is a package tree

-src
  -entity
  -dao
    -impl
  -service
    -impl
  -rest
    -impl
  -web
  -utils
  -config
  -common
     -enums
     -exceptions

So do I need to write a unit test for the following classes : 

utils/DateUtils.java
entity/User.java
web/RegisterUserBeanAction.java
dao/UserDao.java
commons/enums/UserTypeEnum.java

If yes so I wonder how testing a class like User.java just has some properties with setters and getters would be

If no so what the rule then ?

6

Business rules are the most important thing to test. Those should be in behavior objects (objects that DO things) not in value objects (getters and setters).

Testing should never be done blindly or by rote. It should help you refactor and go fast. If it's not doing that something is wrong.

There are things that don't have a strong need to be tested. Like GUI's that have no logic. Now that doesn't mean you can't test them. But testing a value object in a strongly typed language is duplicating what the type system already does for you.

5
  • 1
    Thanks for answering but what about testing for example that username which is a field in User object should have 6 character minimum and that rule is generalized in the whole system and when I think about I just need to run this test case in registration services but what if user has other rules like also password should be 6 or more So I suppose running UserTest.java class should be done on registration service I then got interrupted should unit test UserServiceTest calls unit test UserTest?? this seems ugly!!! Sorry for long message but I got very confused!!!
    – Youans
    Sep 16 '17 at 22:57
  • 1
    You're referring to validation rules. If you insist on baking them into your value object then yes it needs testing beyond the typing system. The tests should make validation fail every way it can fail and pass right up against every way it can pass. That is, test both sides of every boundary.
    – candied_orange
    Sep 17 '17 at 1:37
  • Reason why you don't need to test data objects is simply because you already tested them in the unit tests of classes which usevthem
    – Fabio
    Sep 17 '17 at 4:39
  • Value objects contain business logic as well. VO != DTO.
    – Andy
    Sep 17 '17 at 5:10
  • 1
    Probably, OP's VO (User) has no business at all. It's just the object mapped against the DB. Such object is tested frequently by other unit/integration tests. I would not consider to do unit testing of these entities because the cost-benefit (aside of the arguments exposed in the above answers).
    – Laiv
    Sep 17 '17 at 13:50
3

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.

Code in the first category -- "obviously no deficiencies" -- doesn't need unit tests.

Kent Beck offered these heuristics

If I don’t typically make a kind of mistake (like setting the wrong variables in a constructor), I don’t test for it. I do tend to make sense of test errors, so I’m extra careful when I have logic with complicated conditionals. When coding on a team, I modify my strategy to carefully test code that we, collectively, tend to get wrong.

Your unit tests should normally be focused on the observable behaviors in your system. So refactoring a private method into a new "method object" doesn't necessarily mean that you need to introduce a new battery of tests (although you are welcome to do so).

This site is temporarily in read only mode and not accepting new answers.

Not the answer you're looking for? Browse other questions tagged .