Over a million developers have joined DZone.

How to Verify Equality Without Equals Method

When testing it is often quite complicated to compare object with complex fields. By using the Unitils library in Java, this all becomes quite simple and elegant.

· Agile Zone

Reduce testing time & get feedback faster through automation. Read the Benefits of Parallel Testing, brought to you in partnership with Sauce Labs.

I don’t like the equals method, it often requires very ugly code, therefore I try to avoid the need for it as much as possible. But how do you compare objects during testing? This blog post covers just that.

You may argue, that there are various alternatives for generating the equals method or make it more maintainable. For example:

But what about testing it? I met so many developers that were surprised after hearing about unit testing of the equals method. So should we unit test it? YES, of course! If it’s generated by IDE, it often has a lot of null check if statements. Testing such code means covering a lot of test scenarios, besides which the static code analyzer will probably complain about cyclomatic complexity violations.

If you are using objects with custom equals methods in HashMap or HashSet, we need to conform to the hashCode vs equals contract. Eventual issues in this contract can lead to very tricky behavior of our map or set. Therefore I prefer to use some unique String or numeric representation as a key in the map so that I don’t need to create an equals method.  HashSet is a type I try to avoid completely.

So if most common reasons for creating the equals method for production code are avoided, what about testing? Assertions in tests often require comparison of complex objects making sure that their child fields have the same values. Of course it doesn’t make sense to create equals only for testing assertions. Sometimes we also have nested types to compare. And what about comparison of arrays or lists during testing?

Luckily there is a very neat library called Unitils. It provides various testing helpers for Hibernate, Database and I/O testing or mocking. But I was only using a module called Reflection assert. It makes camparison of Java objects a piece of cake during testing.

Example Objects

package net.lkrnac.blog.reflectioncompare;

public class Address {
    private String line1;
    private String line2;
    private String city;
    private String postalCode;

    public Address(String line1, String line2, String city, String postalCode) {
        this.line1 = line1;
        this.line2 = line2;
        this.city = city;
        this.postalCode = postalCode;
    }

    public String getLine1() {
        return line1;
    }

    public String getLine2() {
        return line2;
    }

    public String getCity() {
        return city;
    }

    public String getPostalCode() {
        return postalCode;
    }
}


package net.lkrnac.blog.reflectioncompare;

public class Person {
    private String firstName;
    private String lastName;
    private Address address;

    public Person(String firstName, String lastName, Address address) {
        this.firstName = firstName;
        this.lastName = lastName;
        this.address = address;
    }

    public String getFirstName() {
        return firstName;
    }

    public String getLastName() {
        return lastName;
    }

    public Address getAddress() {
        return address;
    }
}

Notice that Address is nested field in Person class.

Reflection Equals Verification

Now let’s take a look how we would compare instances of above listed types.

package net.lkrnac.blog.reflectioncompare;

import org.junit.Test;

import static org.unitils.reflectionassert.ReflectionAssert.assertReflectionEquals;

public class VerifyObjectsTest {
    @Test
    public void testObjectsSuccess() {
        Address expectedAddress = new Address("Barad-dûr", "Mount Doom", "Mordor", "1");
        Person expectedPerson = new Person("Sauron", null, expectedAddress);

        Address actualAddress = new Address("Barad-dûr", "Mount Doom", "Mordor", "1");
        Person actualPerson = new Person("Sauron", null, actualAddress);

        assertReflectionEquals(expectedPerson, actualPerson);
    }

    @Test
    public void testObjectsFail() {
        Address expectedAddress = new Address("Barad-dûr", null, "Mordor", "1");
        Person expectedPerson = new Person("Sauron", null, expectedAddress);

        Address actualAddress = new Address("Barad-dûr", "Mount Doom", "Mordor", "1");
        Person actualPerson = new Person("Sauron", null, actualAddress);

        assertReflectionEquals(expectedPerson, actualPerson);
    }
}

The first test method created two separate instances of Person and compared them. The second test method intentionally created differences in the Address  instances it created between actual and expected, so that we can explore Unitils output:

junit.framework.AssertionFailedError: 
Expected: Person<firstName="Sauron", lastName=null, address=Address<line1="Barad-dûr", line2=null, city="Mordor", postalCode="1">>
  Actual: Person<firstName="Sauron", lastName=null, address=Address<line1="Barad-dûr", line2="Mount Doom", city="Mordor", postalCode="1">>

--- Found following differences ---
address.line2: expected: null, actual: "Mount Doom"

--- Difference detail tree ---
 expected: Person<firstName="Sauron", lastName=null, address=Address<line1="Barad-dûr", line2=null, city="Mordor", postalCode="1">>
   actual: Person<firstName="Sauron", lastName=null, address=Address<line1="Barad-dûr", line2="Mount Doom", city="Mordor", postalCode="1">>

address expected: Address<line1="Barad-dûr", line2=null, city="Mordor", postalCode="1">
address   actual: Address<line1="Barad-dûr", line2="Mount Doom", city="Mordor", postalCode="1">

address.line2 expected: null
address.line2   actual: "Mount Doom"

The output is very well presented making the nested difference very obvious.

Comparison of Arrays and Collections

Another very useful use case of Unitils Reflections assert module is comparison of arrays and collections:

package net.lkrnac.blog.reflectioncompare;

import org.junit.Test;
import org.unitils.reflectionassert.ReflectionComparatorMode;

import static java.util.Arrays.asList;
import static org.unitils.reflectionassert.ReflectionAssert.assertReflectionEquals;

public class VerifyArraysTest {

    @Test
    public void testCompareArraysSuccess() {
        String [] expectedArray = new String []{"string1", "string2", "string3"};
        String [] actualArray = new String []{"string1", "string3", "string2"};

        assertReflectionEquals(expectedArray, actualArray, ReflectionComparatorMode.LENIENT_ORDER);
    }

    @Test
    public void testCompareArraysFail() {
        String [] expectedArray = new String []{"string1", "string2", "string3"};
        String [] actualArray = new String []{"string1", "string3", "string2"};

        assertReflectionEquals(expectedArray, actualArray);
    }

    @Test
    public void testCompareCollectionsSuccess() {
        String [] expectedArray = new String []{"string1", "string2", "string3"};
        String [] actualArray = new String []{"string1", "string3", "string2"};

        assertReflectionEquals(asList(expectedArray), asList(actualArray), ReflectionComparatorMode.LENIENT_ORDER);
    }

    @Test
    public void testCompareCollectionsFail() {
        String [] expectedArray = new String []{"string1", "string2", "string3"};
        String [] actualArray = new String []{"string1", "string3", "string2"};

        assertReflectionEquals(asList(expectedArray), asList(actualArray));
    }
}

The first test method compares arrays and although the array elements are ordered differently it will succeed, because we instructed Unitils to ignore the order of elements in the array with this parameter ReflectionComparatorMode.LENIENT_ORDER. In the second test method, we don’t use the reflection comparator mode parameter, so order matters. Because it’s is different for actual and expected arrays, test will fail with this output:

junit.framework.AssertionFailedError: 
Expected: ["string1", "string2", "string3"]
  Actual: ["string1", "string3", "string2"]

--- Found following differences ---
[1]: expected: "string2", actual: "string3"
[2]: expected: "string3", actual: "string2"

--- Difference detail tree ---
 expected: ["string1", "string2", "string3"]
   actual: ["string1", "string3", "string2"]

[1] expected: "string2"
[1]   actual: "string3"

[2] expected: "string3"
[2]   actual: "string2"

Again very detailed output about test failure.

Lastly the library also has test methods for comparing lists, so Unitils Reflection assert module can also be used on Java collections.

Example code is hosted on Github.

The Agile Zone is brought to you in partnership with Sauce Labs. Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure.

Topics:
testing ,reflection ,assertions ,java

Published at DZone with permission of Lubos Krnac, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}