Assertion error when comparing field by field is no longer as informative

[markstamatiades]

class Person {
    public String getFirstName() {
        return firstName;
    }

    public String getLastName() {
        return lastName;
    }

    private String firstName, lastName;

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

class PersonDAO {

    public String getFirstname() {
        return firstname;
    }

    public String getLastname() {
        return lastname;
    }

    public Long getId() {
        return id;
    }

    public Integer getAge() {
        return age;
    }

    private String firstname, lastname;
    private Long id;
    private Integer age;

    public PersonDAO(String firstname, String lastname, Long id, Integer age) {
        this.firstname = firstname;
        this.lastname = lastname;
        this.id = id;
        this.age = age;
    }
}

Person person = new Person("John", "Doe");
PersonDAO personDAO = new PersonDAO("John", "Doe", 1L, 23);

assertThat(person).isEqualToComparingFieldByFieldRecursively(personDAO);

In AssertJ 3.6.2, an IntrospectionError was thrown when a field or property was missing/different when comparing one object to another of two different types. In this case, Person contains FirstName and LastName whereas PersonDAO contains Firstname and Lastname.

Exception in thread "main" org.assertj.core.util.introspection.IntrospectionError: 
Can't find any field or property with name 'firstName'.
Error when introspecting properties was :
- No getter for property 'firstName' in PersonDAO 
Error when introspecting fields was :
- Unable to obtain the value of the field <'firstName'> from <PersonDAO@506c589e>
	at org.assertj.core.util.introspection.PropertyOrFieldSupport.getSimpleValue(PropertyOrFieldSupport.java:79)
	at org.assertj.core.internal.DeepDifference.initStack(DeepDifference.java:327)
	at org.assertj.core.internal.DeepDifference.determineDifferences(DeepDifference.java:153)
	at org.assertj.core.internal.Objects.assertIsEqualToComparingFieldByFieldRecursively(Objects.java:711)
	at org.assertj.core.api.AbstractObjectAssert.isEqualToComparingFieldByFieldRecursively(AbstractObjectAssert.java:632)
	at Main.main(Main.java:20)

In 3.7.0 and above, only the following is returned:

Exception in thread "main" java.lang.AssertionError: 
Expecting:
  <Person@7aec35a>
to be equal to:
  <PersonDAO@67424e82>
when recursively comparing field by field, but found the following difference(s):

Path to difference: <>
- expected: <PersonDAO@67424e82>
- actual  : <Person@7aec35a>

Requires a lot more work to figure out exactly why the assertion fails, especially when the objects become much more complex and interfaces are included. Would be good if the original error information could be returned like it was in 3.6.2.

[joel-costigliola]

I agree the error is not helpful, thanks for reporting this !

[joel-costigliola]

I was thinking to change the error returned to show all the missing fields, ex:

Employee employee = new Employee();
EmployeeOfTheMonth employeeOfTheMonth = new EmployeeOfTheMonth();

assertThat(employeeOfTheMonth).isEqualToComparingFieldByFieldRecursively(employee);

The assertion fails with the error:

Expecting:
  <org.assertj.examples.custom.EmployeeOfTheMonth@6591f517>
to be equal to:
  <org.assertj.examples.custom.Employee@345965f2>
when recursively comparing field by field, but found the following difference(s):

Path to difference: <>
- expected: <org.assertj.examples.custom.Employee@345965f2>
- actual  : <org.assertj.examples.custom.EmployeeOfTheMonth@6591f517>
- reason  : org.assertj.examples.custom.EmployeeOfTheMonth can't be compared to org.assertj.examples.custom.Employee as Employee does not declare all EmployeeOfTheMonth fields, it lacks these:[month]

@markstamatiades WDYT ?

[markstamatiades]

Looks reasonable to me. So if there is more than one missing field it will list them all rather than just the first one it hits, right?

[rossmasday]

What would the message be if the fields had the same name but were of differing types?

[joel-costigliola]

@markstamatiades yes it would show all the missing fields
@rossmasday there would not be such a message as the field names are matching but when comparing their values it will likely fail.