Do I need to do unit testing of the system entities?

Asked

Viewed 783 times

3

I am working on a project and participating in a team , we were given the task of doing a series of tests with a system,testes de integração continua, testes unitários ....
The point is that all systems have entity classes and business rules. So ,it is very interesting to test the classes of business rules.
My entity classes only have the usual:

atributos  
getters() and setters()   
construtor()  
toString()  
equals()   
hashcode()  
compareTo()

But I have a doubt about the classes of entity:
I must do testes unitários for my classes of entity (Beans or pojos) since they have no business rule?

  • 2

    There is behavior in their entities (in addition to equals, hashCode, toString)? Only you can tell if tests are needed in this layer, but the answer to an application developed following DDD principles will probably be quite different from the answer to an application with a more anemic model. Test what to add value.

2 answers

4


There is no unit test of getters and setters, which are the methods contained in POJOS. For any other method one should create the unit tests. It is good to keep in mind that the idea of a unit test is that its execution may result in failure if there is a change in the target class/method of the test. This way it does not make sense to test Pojos because its methods are only recovery and modification by default, often automatically generated including.

1

As Giuliana Bezerra said, there is no point in testing getters/setters. The same applies for equals(), hashcode() etc. The methods that should have their behavior tested are those that involve rules of negotiation and whose change can impact the evolution of the system - to avoid regression. Testing getters/setters adds nothing to your test suite.

When deciding whether a unit test should be written I suggest thinking about some points:

  1. What is the complexity of the method/class in question?
  2. What is the importance of the method/class in the module/system/application? (i.e: how many classes depend on that code - this is an indication that that code may prove to be a crucial point of failure in the system)
  3. What is the possibility of that code being maintained in the future? (maintenance means change of code and for it to be safer, nothing better than having tests that ensure the functioning. The more tests, the less afraid we have of changing a code)

PS.: I find it strange that these entities of yours only have these kinds of methods. Remember that object orientation involves attributes and behaviors. I think, without knowing much of the structure of your project, that maybe your classes should be rethought. I suggest reading the Martin Fowler’s article on the Anemic Model to know a little more.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.