Unit testing equals and hashcode - a complexity story

Asked 2011-04-23T13:18:38.263

I'm having a moral dilemma. I have some value objects in my application, which are immutable and extremely simple. I've generated the equals and hashcode with an IDE (intellij in my case) but doing that, made the code coverage drop, plus the reports now indicate that those value objects are very complex (using the cyclomatic complexity metric) when in fact they're dead simple.

As an example, the following equals is in a value object that has 3 immutable attributes. The Code complexity is 14 (javaNCSS) and it has 26 execution branches (Cobertura). I should add too, that I fail the build if any method has a complexity greater than 10.

@Override
public boolean equals(Object o) {
    if (this == o) {
        return true;
    }
    if (o == null || getClass() != o.getClass()) {
        return false;
    }

    TranscriptTaskDetails that = (TranscriptTaskDetails) o;

    if (inputFile != null ? !inputFile.equals(that.inputFile) : that.inputFile != null) {
        return false;
    }
    if (language != that.language) {
        return false;
    }
    if (outputFile != null ? !outputFile.equals(that.outputFile) : that.outputFile != null) {
        return false;
    }

    return true;
}

I'm wondering what other devs use to circumvent this, as I pay quite a lot of attention to the complexity reports, as in my experience a high complexity metric relates to more bugs, so this auto-generated equals and hashcodes are polluting the reports.

I'm thinking of using EqualsBuilder and HashcodeBuilder from apache commons-lang to circumvent this, but I'm not 100% happy :S.

Edit

I should have added that part of the code I'm writing for this project is a library that will be used by other business units... And will be maintained by a different team too :S.

Edit Report

3 Answers

How high is your code coverage? Some people argue that shooting for 100% is a sign of anal retentive tendencies. If you're in the 70-80% range, and you know that what you haven't tested isn't a problem, then why worry about it?

On the other hand, these tests aren't that difficult to write. Why not write them, be done with it, and sleep at night ? You would have finished the test in the time it took to type your moral dilemma here and waiting for answers.

answered 2011-04-23T13:24:46.703

Simple POJOs - immutable with or without builders, or mutable, are at best automatically generated from a simple DSL description in the first place, until Java gets direct language support for this simple, yet important feature.

answered 2013-05-13T22:10:05.667

In my opinion, seeing code coverage drop is an indicator that you should have a look at the code and find out by yourself if the drop in coverage is justified. Code metrics on things like generated equals or hashcode are not really important, they are so simple that they just work. Same for simple getters and setters, who really cares if some of them are not covered? (That may be a symptom of some other thing not being tested though, but that is beside the point).

Tools are here to help us write good code and applications... we should not be slaves to them.

answered 2011-04-23T13:49:56.660

Unit testing equals and hashcode - a complexity story

Edit

3 Answers

Your Answer