Preamble: Let's say I aim to cover all my classes with test coverage.
Despite the common opinion (expecially in Java community) to "not pay too much attention to Cyclomatic Complexity (CC) and code coverage", I really think that these information are extremely useful: When you have a very high CC, or an uncovered zone in your code, very likely you wrote a dead code, or either is a smell that you have problems in design. In my personal experience I can say that many time dead code is code smell.
This problem become a little tricky when you have to deal with auto-generated code, and that's the point, how can I easily deal with
equals autogenerated methods?
I came across this question in StackOverflow and I realized some very good point:
But this question is not a duplicate because I want to use a different approach:
The best options available in the answers of that question are, as far as I can see, EqualsBuilder of Apache Commons Lang or Guava. Both uses reflection (correct me if I'm wrong) and that could be a problem for performance in some situations.
But my actual question is: Since most of the times both
hashcode methods are not covered, is that a hint that this particular class does not need those 2 methods?
Since many Java developers a lot of time generate equals and hashcode even when not needed, what am I missing?
Shouldn't be a better solution to generate those methods only when you need, for instance, to sort objects of that class, to use that objects as an Hashtable key, and so on?
As I said, I think that goals of low complexity and high coverage are admirable, but the solution of using EqualsTester , seems to me like "Force to cover code that you don't actually need in your program".