¿Cómo afirmo la igualdad en dos clases sin un método igual?

Digamos que tengo una clase sin método equals (), para la cual no tengo la fuente. Quiero afirmar la igualdad en dos instancias de esa clase.

Puedo hacer varias afirmaciones:

assertEquals(obj1.getFieldA(), obj2.getFieldA());
assertEquals(obj1.getFieldB(), obj2.getFieldB());
assertEquals(obj1.getFieldC(), obj2.getFieldC());
...

No me gusta esta solución porque no obtengo la imagen de igualdad completa si falla una afirmación temprana.

Puedo comparar manualmente por mi cuenta y rastrear el resultado:

String errorStr = "";
if(!obj1.getFieldA().equals(obj2.getFieldA())) {
    errorStr += "expected: " + obj1.getFieldA() + ", actual: " + obj2.getFieldA() + "\n";
}
if(!obj1.getFieldB().equals(obj2.getFieldB())) {
    errorStr += "expected: " + obj1.getFieldB() + ", actual: " + obj2.getFieldB() + "\n";
}
...
assertEquals("", errorStr);

Esto me da una imagen de igualdad completa, pero es torpe (y ni siquiera he tenido en cuenta los posibles problemas de nulos). Una tercera opción es usar Comparator, pero compareTo () no me dirá qué campos fallaron en la igualdad.

¿Existe una mejor práctica para obtener lo que quiero del objeto, sin subclasificar y anular iguales (ugh)?

Mockito ofrece un comparador de reflejos:

Para la última versión de Mockito use:

Assert.assertTrue(new ReflectionEquals(expected, excludeFields).matches(actual));

Para versiones anteriores, use:

Assert.assertThat(actual, new ReflectionEquals(expected, excludeFields));

Aquí hay muchas respuestas correctas, pero también me gustaría agregar mi versión. Esto se basa en Assertj.

import static org.assertj.core.api.Assertions.assertThat;

public class TestClass {

    public void test() {
        // do the actual test
        assertThat(actualObject)
            .isEqualToComparingFieldByFieldRecursively(expectedObject);
    }
}

ACTUALIZACIÓN: En assertj v3.13.2 este método está en desuso, como señaló Woodz en el comentario. La recomendación actual es

public class TestClass {

    public void test() {
        // do the actual test
        assertThat(actualObject)
            .usingRecursiveComparison()
            .isEqualTo(expectedObject);
    }

}

Generalmente implemento este caso de uso usando org.apache.commons.lang3.builder.EqualsBuilder

Assert.assertTrue(EqualsBuilder.reflectionEquals(expected,actual));

Sé que es un poco viejo, pero espero que ayude.

Me encontré con el mismo problema que tú, así que, después de investigar, encontré pocas preguntas similares a esta y, después de encontrar la solución, respondo lo mismo en esas, ya que pensé que podría ayudar a otros.

La respuesta más votada (no la elegida por el autor) de este pregunta similar , es la solución más adecuada para usted.

Básicamente, consiste en utilizar la biblioteca llamada Unitils .

Este es el uso:

User user1 = new User(1, "John", "Doe");
User user2 = new User(1, "John", "Doe");
assertReflectionEquals(user1, user2);

Que pasará incluso si la clase Userno se implementa equals(). Puede ver más ejemplos y una afirmación realmente genial llamada assertLenientEqualsen su tutorial .

Puedes usar Apache commons lang ReflectionToStringBuilder

Puede especificar los atributos que desea probar uno por uno, o mejor, excluir aquellos que no desea:

String s = new ReflectionToStringBuilder(o, ToStringStyle.SHORT_PREFIX_STYLE)
                .setExcludeFieldNames(new String[] { "foo", "bar" }).toString()

Luego compara las dos cadenas de forma normal. En cuanto a que la reflexión es lenta, supongo que esto es solo para probar, por lo que no debería ser tan importante.

Si está usando hamcrest para sus afirmaciones (assertThat) y no desea extraer bibliotecas de prueba adicionales, puede usar SamePropertyValuesAs.samePropertyValuesAs para afirmar elementos que no tienen un método igual anulado.

La ventaja es que no tiene que incorporar otro marco de prueba más y dará un error útil cuando la aserción falla ( expected: field=<value> but was field=<something else>) en lugar de expected: true but was falsesi usa algo como EqualsBuilder.reflectionEquals().

La desventaja es que es una comparación superficial y no hay opción para excluir campos (como en EqualsBuilder), por lo que tendrá que trabajar con objetos anidados (por ejemplo, eliminarlos y compararlos de forma independiente).

Mejor caso:

import static org.hamcrest.beans.SamePropertyValuesAs.samePropertyValuesAs;
...
assertThat(actual, is(samePropertyValuesAs(expected)));

Caso feo:

import static org.hamcrest.beans.SamePropertyValuesAs.samePropertyValuesAs;
...
SomeClass expected = buildExpected(); 
SomeClass actual = sut.doSomething();

assertThat(actual.getSubObject(), is(samePropertyValuesAs(expected.getSubObject())));    
expected.setSubObject(null);
actual.setSubObject(null);

assertThat(actual, is(samePropertyValuesAs(expected)));

Entonces, elige tu veneno. Marco adicional (por ejemplo, Unitils), error inútil (por ejemplo, EqualsBuilder) o comparación superficial (hamcrest).

La biblioteca Hamcrest 1.3 Utility Matchers tiene un matcher especial que utiliza la reflexión en lugar de iguales.

assertThat(obj1, reflectEquals(obj2));

Algunos de los métodos de comparación de reflexión son superficiales

Otra opción es convertir el objeto a json y comparar las cadenas.

import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.databind.ObjectMapper;    
public static String getJsonString(Object obj) {
 try {
    ObjectMapper objectMapper = new ObjectMapper();
    return bjectMapper.writerWithDefaultPrettyPrinter().writeValueAsString(obj);
     } catch (JsonProcessingException e) {
        LOGGER.error("Error parsing log entry", e);
        return null;
    }
}
...
assertEquals(getJsonString(MyexpectedObject), getJsonString(MyActualObject))

Con Shazamcrest , puede hacer:

assertThat(obj1, sameBeanAs(obj2));

Comparar campo por campo:

assertNotNull("Object 1 is null", obj1);
assertNotNull("Object 2 is null", obj2);
assertEquals("Field A differs", obj1.getFieldA(), obj2.getFieldA());
assertEquals("Field B differs", obj1.getFieldB(), obj2.getFieldB());
...
assertEquals("Objects are not equal.", obj1, obj2);

Las afirmaciones de AssertJ se pueden usar para comparar los valores sin que el #equalsmétodo se anule correctamente, por ejemplo:

import static org.assertj.core.api.Assertions.assertThat; 

// ...

assertThat(actual)
    .usingRecursiveComparison()
    .isEqualTo(expected);

Dado que esta pregunta es antigua, sugeriré otro enfoque moderno utilizando JUnit 5.

No me gusta esta solución porque no obtengo la imagen de igualdad completa si falla una afirmación temprana.

Con JUnit 5, hay un método llamado Assertions.assertAll()que le permitirá agrupar todas las aserciones en su prueba y ejecutará cada una y generará las aserciones fallidas al final. Esto significa que cualquier afirmación que falle primero no detendrá la ejecución de las últimas afirmaciones.

assertAll("Test obj1 with obj2 equality",
    () -> assertEquals(obj1.getFieldA(), obj2.getFieldA()),
    () -> assertEquals(obj1.getFieldB(), obj2.getFieldB()),
    () -> assertEquals(obj1.getFieldC(), obj2.getFieldC()));

Puede utilizar la reflexión para "automatizar" la prueba de igualdad total. puede implementar el código de "seguimiento" de igualdad que escribió para un solo campo, luego usar la reflexión para ejecutar esa prueba en todos los campos del objeto.

Este es un método de comparación genérico, que compara dos objetos de una misma clase por los valores de sus campos (tenga en cuenta que se puede acceder a ellos mediante el método get)

public static <T> void compare(T a, T b) throws NoSuchMethodException, InvocationTargetException, IllegalAccessException {
    AssertionError error = null;
    Class A = a.getClass();
    Class B = a.getClass();
    for (Method mA : A.getDeclaredMethods()) {
        if (mA.getName().startsWith("get")) {
            Method mB = B.getMethod(mA.getName(),null );
            try {
                Assert.assertEquals("Not Matched = ",mA.invoke(a),mB.invoke(b));
            }catch (AssertionError e){
                if(error==null){
                    error = new AssertionError(e);
                }
                else {
                    error.addSuppressed(e);
                }
            }
        }
    }
    if(error!=null){
        throw error ;
    }
}

Me encontré con un caso muy similar.

Quería comparar en una prueba de que un objeto tiene los mismos valores de atributos como la otra, pero los métodos como is(), refEq(), etc, no haría el trabajo por razones como mi objeto que tiene un valor nulo en suid atributo.

Así que esta fue la solución que encontré (bueno, un compañero de trabajo encontró):

import static org.apache.commons.lang.builder.CompareToBuilder.reflectionCompare;

assertThat(reflectionCompare(expectedObject, actualObject, new String[]{"fields","to","be","excluded"}), is(0));

Si el valor obtenido de reflectionComparees 0, significa que son iguales. Si es -1 o 1, difieren en algún atributo.

En el caso común con AssertJ, puede crear una estrategia de comparación personalizada:

assertThat(frodo).usingComparator(raceComparator).isEqualTo(sam)
assertThat(fellowshipOfTheRing).usingElementComparator(raceComparator).contains(sauron);

Usar una estrategia de comparación personalizada en afirmaciones

Ejemplos de AssertJ

Tenía exactamente el mismo acertijo cuando probaba unitariamente una aplicación de Android, y la solución más fácil que se me ocurrió fue simplemente usar Gson para convertir mis objetos de valor real y esperado jsony compararlos como cadenas.

String actual = new Gson().toJson( myObj.getValues() );
String expected = new Gson().toJson( new MyValues(true,1) );

assertEquals(expected, actual);

Las ventajas de esto sobre la comparación manual campo por campo es que usted compara todos sus campos, por lo que incluso si luego agrega un nuevo campo a su clase, se probará automáticamente, en comparación con si estuviera usando un montón deassertEquals() de todos los campos, que luego deberían actualizarse si agrega más campos a su clase.

jUnit también muestra las cadenas para que pueda ver directamente en qué se diferencian. Sin Gsonembargo, no estoy seguro de cuán confiable sea el pedido de campo , eso podría ser un problema potencial.

Probé todas las respuestas y nada realmente funcionó para mí.

Así que he creado mi propio método que compara objetos java simples sin profundizar en estructuras anidadas ...

El método devuelve un valor nulo si todos los campos coinciden o la cadena contiene detalles que no coinciden.

Solo se comparan las propiedades que tienen un método getter.

Cómo utilizar

        assertNull(TestUtils.diff(obj1,obj2,ignore_field1, ignore_field2));

Salida de muestra si hay una discrepancia

La salida muestra los nombres de las propiedades y los valores respectivos de los objetos comparados

alert_id(1:2), city(Moscow:London)

Código (Java 8 y superior):

 public static String diff(Object x1, Object x2, String ... ignored) throws Exception{
        final StringBuilder response = new StringBuilder();
        for (Method m:Arrays.stream(x1.getClass().getMethods()).filter(m->m.getName().startsWith("get")
        && m.getParameterCount()==0).collect(toList())){

            final String field = m.getName().substring(3).toLowerCase();
            if (Arrays.stream(ignored).map(x->x.toLowerCase()).noneMatch(ignoredField->ignoredField.equals(field))){
                Object v1 = m.invoke(x1);
                Object v2 = m.invoke(x2);
                if ( (v1!=null && !v1.equals(v2)) || (v2!=null && !v2.equals(v1))){
                    response.append(field).append("(").append(v1).append(":").append(v2).append(")").append(", ");
                }
            }
        }
        return response.length()==0?null:response.substring(0,response.length()-2);
    }

Como alternativa para junit-only, puede establecer los campos en nulos antes de la aserción igual:

    actual.setCreatedDate(null); // excludes date assertion
    expected.setCreatedDate(null);

    assertEquals(expected, actual);

¿Puede poner el código de comparación que publicó en algún método de utilidad estática?

public static String findDifference(Type obj1, Type obj2) {
    String difference = "";
    if (obj1.getFieldA() == null && obj2.getFieldA() != null
            || !obj1.getFieldA().equals(obj2.getFieldA())) {
        difference += "Difference at field A:" + "obj1 - "
                + obj1.getFieldA() + ", obj2 - " + obj2.getFieldA();
    }
    if (obj1.getFieldB() == null && obj2.getFieldB() != null
            || !obj1.getFieldB().equals(obj2.getFieldB())) {
        difference += "Difference at field B:" + "obj1 - "
                + obj1.getFieldB() + ", obj2 - " + obj2.getFieldB();
        // (...)
    }
    return difference;
}

Entonces puedes usar este método en JUnit así:

assertEquals ("Los objetos no son iguales", "", findDifferences (obj1, obj));

que no es torpe y le brinda información completa sobre las diferencias, si existen (a través de no exactamente en la forma normal de assertEqual, pero obtiene toda la información, por lo que debería ser bueno).

Esto no ayudará al OP, pero podría ayudar a cualquier desarrollador de C # que termine aquí ...

Como publicó Enrique , debes anular el método de iguales.

¿Existe una mejor práctica para obtener lo que quiero del objeto, sin subclasificar y anular iguales (ugh)?

Mi sugerencia es no utilizar una subclase. Utilice una clase parcial.

Definiciones de clases parciales (MSDN)

Entonces tu clase se vería así ...

public partial class TheClass
{
    public override bool Equals(Object obj)
    {
        // your implementation here
    }
}

Para Java, estaría de acuerdo con la sugerencia de usar la reflexión. Solo recuerda que debes evitar usar la reflexión siempre que sea posible. Es lento, difícil de depurar e incluso más difícil de mantener en el futuro porque los IDE podrían romper su código al cambiar el nombre de un campo o algo así. ¡Ten cuidado!

De sus comentarios a otras respuestas, no entiendo lo que quiere.

Solo por el bien de la discusión, digamos que la clase anuló el método de igualdad.

Entonces su UT se verá algo como:

SomeType expected = // bla
SomeType actual = // bli

Assert.assertEquals(expected, actual). 

Y ya está. Además, no puede obtener la "imagen de igualdad total" si la afirmación falla.

Por lo que tengo entendido, está diciendo que incluso si el tipo anulara los iguales, no estaría interesado en él, ya que desea obtener la "imagen de igualdad total". Por lo tanto, tampoco tiene sentido extender y anular iguales.

Entonces tiene opciones: o comparar propiedad por propiedad, usando la reflexión o verificaciones codificadas, sugeriría lo último. O: compare representaciones legibles por humanos de estos objetos.

Por ejemplo, puede crear una clase auxiliar que serialice el tipo que desea comparar con un documento XML y luego comparar el XML resultante. en este caso, puede ver visualmente qué es exactamente igual y qué no.

Este enfoque le dará la oportunidad de ver la imagen completa, pero también es relativamente engorroso (y un poco propenso a errores al principio).

Puede anular el método equals de la clase como:

@Override
public int hashCode() {
    int hash = 0;
    hash += (app != null ? app.hashCode() : 0);
    return hash;
}

@Override
public boolean equals(Object object) {
    HubRule other = (HubRule) object;

    if (this.app.equals(other.app)) {
        boolean operatorHubList = false;

        if (other.operator != null ? this.operator != null ? this.operator
                .equals(other.operator) : false : true) {
            operatorHubList = true;
        }

        if (operatorHubList) {
            return true;
        } else {
            return false;
        }
    } else {
        return false;
    }
}

Bueno, si desea comparar dos objetos de una clase, debe implementar de alguna manera el método equals y el código hash