As Giuliana Bezerra said, it does not make sense to test getters / setters. The same applies to for equals (), hashCode (), and so on. The methods that should have their behavior tested are those that involve business rules and whose change can impact the evolution of the system - to avoid regression. Testing getters / setters does not add anything to your test suite.
At the moment of deciding if a unit test should be written I suggest thinking about some points:
What is the complexity of the method / class in question?
What is the importance of the method / class in the module / system / application? (ie how many classes depend on that code - this is an indication that that code may turn out to be a crucial point of failure in the system)
What is the possibility of this code being maintained in the future? (maintenance means changing the code and for this to be safer, nothing better than having tests that ensure the operation.) The more tests, the less fear we have to change a code)
PS: I find it strange that your entities only have these types of methods. Remember that object orientation involves attributes and behaviors. I think, without knowing much about 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 learn more.