• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Junit testing for model classes

 
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I wonder your opinions about unit testing for model classes in MVC environment.

Lets assume that I am developing a java web project and using mvc pattern, so i have model classes for each database table.
Do I have to define unit test for model classes?
Because model classes generally have methods like getX() and setX(...)? What is the gain of testing these method?
Maybe, equals or hashCode is the only methods that should be tested I think.
 
Ranch Hand
Posts: 143
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My two cents:

If you are generating the data model getter/setters then at a glance testing may seem useless, but if you do not have tests in place then you invite potential for unexpected behavior at some point. What happens if someone breaks the getX/setX and returns a value Y on the getX or fails to store X (or stores it in Y) on the setX? Do you have any business logic in the model (such as range checking or other data validations)?

Similar arguments can be made beyond the object data in memory, as you work with the persistent storage. What if the object mappings do not line up with the database columns you expect? A setX could be stored in column "Y" and on later retrieval be returned in Y. If you are lucky you get some sort of data exception and know to look for a problem. If you have columns that place nicely with the mixed up types howerver, then you just have bad data.

Depending on how you map to the database, then you may not be testing your java code any longer. For example, if you use a framework such as Spring or Hibernate then in some cases you are arguabbly are more testing your configuration files which link the data and the DB. This is still part of your application solution, and assuming you deliver this with the install then you want to make sure it works.

 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In a "pure" MVC environment, there wouldn't be much point. You put a property value in, you should get the same property out. End of story.

In the Real World, however, models aren't always pure. A very common digression at the moment is the JSF Backing Bean. JSF Backing Beans are mostly models, but they also typically have logic in them as well - a characteristic that causes a lot of people to incorrectly label them as Controllers and not Models. A Controller, however, is what synchronizes the View and the Model, and the most common type of logic you'll find in them are JSF Action methods, which are not UI controllers, but rather the interface logic between the JSF Model and the rest of the application.

These Action methods very definitely are testable, since the JSF design was based on that premise. Well-written Action methods have little to no JSF-specific code in them, and get most of their operating data from values previously injected into the model. In turn, they may update the model data, which can then be queried by the test.

I do this fairly extensively, in fact.

Other things that can require testing in a model are side-effects (where setting one property cascades into changes to other properties) and converting set/get methods where, for example, values get scaled or modified (such as Fahrenheit/Celsius). Experience has taught me that the fewer instances of these, the happier life is, however, test or no test.

Finally, of course, some objects have a (re)initialize method that sets properties to default values. It can be useful to test and make sure that they do.
reply
    Bookmark Topic Watch Topic
  • New Topic