Тонкая разница между fest и assert-j с пользовательской картой

Question

в проекте, где я работаю, было принято решение прекратить использовать fest для тестовых утверждений, а вместо этого использовать assertj. Мы используем Java 7, и мы переходим от версии версии 2.0M10 к assertj-core версии 2.4.1. Кодовая база довольно большая, но переход от fest к assertj был плавным, в основном меняя имена импорта и справляясь с переименованными методами. Тем не менее, я заметил, что после перехода мы получили тестовые сбои в определенном тестовом классе (я должен добавить, что мы используем JUnit v4.12). Ниже я покажу небольшой автономный TestCase выдвигая на первый план вопрос:

import java.util.Collection; 
import java.util.HashMap; 
import java.util.Map; 
import java.util.Set; 

import org.junit.Before; 
import org.junit.Test; 

class MyMap implements Map<String, Object> { 
    private Map<String, Object> theMap = new HashMap<>(); 

    @Override 
    public int size() { 
     return theMap.size(); 
    } 

    @Override 
    public boolean isEmpty() { 
     return theMap.isEmpty(); 
    } 

    @Override 
    public boolean containsKey(Object key) { 
     return theMap.containsKey(key); 
    } 

    @Override 
    public boolean containsValue(Object value) { 
     return theMap.containsValue(value); 
    } 

    @Override 
    public Object get(Object key) { 
     return theMap.get(key); 
    } 

    @Override 
    public Object put(String key, Object value) { 
     return theMap.put(key, value); 
    } 

    @Override 
    public Object remove(Object key) { 
     return theMap.remove(key); 
    } 

    @Override 
    public void putAll(Map<? extends String, ? extends Object> m) { 
     theMap.putAll(m); 
    } 

    @Override 
    public void clear() { 
     theMap.clear(); 
    } 

    @Override 
    public Set<String> keySet() { 
     return theMap.keySet(); 
    } 

    @Override 
    public Collection<Object> values() { 
     return theMap.values(); 
    } 

    @Override 
    public Set<java.util.Map.Entry<String, Object>> entrySet() { 
     return theMap.entrySet(); 
    } 
} 

public class TestMapComparison { 
    private Map<String, Object> m1 = new HashMap<>(); 
    private MyMap m2 = new MyMap(); 

    @Before 
    public void before() { 
     m1.put("a", "b"); 
     m2.put("a", "b"); 
    } 

    // Fails with: 
    // java.lang.AssertionError: 
    // expected: <'{'a'='b'} (MyMap@6f5fc7ad)'> 
    // but was: <'{'a'='b'} (HashMap@3)'> 
    @Test 
    public void test1_Fest_m1_isEqualTo_m2() { 
     org.fest.assertions.api.Assertions.assertThat(m1).isEqualTo(m2); 
    } 

    @Test // Pass 
    public void test2_AssertJ_m1_isEqualTo_m2() { 
     org.assertj.core.api.Assertions.assertThat(m1).isEqualTo(m2); 
    } 

    @Test // Pass 
    public void test3_Fest_m2_isEqualTo_m1() { 
     org.fest.assertions.api.Assertions.assertThat(m2).isEqualTo(m1); 
    } 

    // Fails with: 
    // java.lang.AssertionError: 
    // Expecting: <"{"a"="b"} (MyMap@5aedacd2)"> 
    // to be equal to: 
    // <"{"a"="b"} (HashMap@3)"> but was not. 
    @Test 
    public void test4_AssertJ_m2_isEqualTo_m1() { 
     org.assertj.core.api.Assertions.assertThat(m2).isEqualTo(m1); 
    } 
} 

Я извиняюсь за такой длинный кусок кода. Как видно из результата теста, существует разница между fest и assertj при использовании isEqualTo() в хэшмапах, где один из хэш-карт инкапсулирован в класс, реализующий карту интерфейса. Мой вопрос в том, как с этим справиться? Я мог бы перевернуть порядок в утверждении, т. Е. Иметь assertThat (b) .isEqualTo (a) вместо того, чтобы иметь assertThat (a) .isEqualTo (b). Но мне кажется немного странным, что я должен сделать такой флип один на конкретном утверждении в большом тестовом классе со многими утверждениями. Является ли это различие между fest и assertj ожидаемым или неожиданным? Ожидается ли поведение от того или другого (так как оба не работают на одном выражении)? Как мне обновить тестовый файл, лучше ли выполнить проверку равенства со сценарием в коде выше? Спасибо, что прочитали это и спасибо за любой совет!

Answer 1

Ну, ошибка в коде, и каждая библиотека заметит ошибку, если вы протестировали договор Equals(), которым должен быть симметричным: А равно B тогда и только тогда B равна A.

Я бы просто исправить свой код и быть счастливым, если бы обнаружил ошибку благодаря миграции. Я бы также улучшил испытания и сделал

assertThat(a).isEqualTo(b); 
assertThat(b).isEqualTo(a); 

, чтобы убедиться, что контракт выполнен.