单元测试，集合的toString相同，而值不同，对象比较的坑

单元测试

前言

最近在写代码的单元测试，说实话，这个单元测试的代码量跟开发的代码还要多，主要是模拟数据比较麻烦，在写单元测试的过程中遇到了一个坑想要分享一下，首先我写单元测试用的最多的就是断言Assert类的方法，所以就从这个类的方法讲起

问题

首先说问题，在使用IDEA写单元测试时，assertEquals(集合A，集合B);会报异常，集合A和集合B包含的元素类型一样，集合大小一样，并且会在控制台打印：

点击蓝色的，会跳出：
这是对比的界面，会将两个对象的不同高亮显示出来，可是我找了好几遍也没找到有不同的，且没有高亮显示，并且我在另一个单元测试方法里面也是如此使用的，另一个就通过了，这个为什么没有，很纳闷。

解决方案

1. 检查代码，是否有写错的，或者有标点符号写错的，或者多了空格什么的，细节要注意。仔细检查确认无误，运行还是报错，点进去还是一模一样，排除测试代码的原因。
2. 既然，两个集合断言判断时不一样的，但是在对比框里面却没有高亮显示，那么就有必要比较一波toString()了，使用方法 assertEquals(集合A.toString(),集合B.toString());代替 assertEquals(集合A,集合B);运行测试，结果就是测试通过，确定集合A和集合B字符串内容是一模一样的，但是为什么比较集合对象是不同的呢？
3. 我们知道在JAVA中，比较两个元素是否相等，一是比较实际值，其次是比较地址值。
   3.1 如果类没有实现equals方法，则默认是比较地址值，实现了equals方法则会调用对象的equals方法
   3.2 如果是使用==来比较两个对象的话，如果是基本类型则比较值，如果是引用类型则比较地址值。
   3.3 查看assertEquals(集合A，集合B)的源码以及相关方法，如下所示：
   
   
   
   
   因为我们传参是List集合，所以最终调用的方法是：

集合A.equals(集合B)

所以根据Debug我发现其实就是调用的AbstractList类的equals方法，实现如下：

List集合的equals方法逻辑就是，首先要保证这俩都是List或其子类，然后两个集合开始比，每个同时按顺序拿出一个元素对比，调用元素的equals方法，对比两个元素是否一样，不一样两个集合就自然不一样，如果相同就继续同事拿出下一个元素进行相比，如果出现一个集合拿得出，另一个集合拿不出元素了，那两个集合就肯定不相等了。其实就是比较集合的大小以及集合内部元素是否相等。
3.4 首先这两个集合大小肯定是相同的，那么排除这个方法的问题，以及集合比较的问题，那么就剩下元素不一样这个可能了
4. 听过一句话，当你面对一件事时，排除了那些绝对不可能的因素外，剩下的那个在不可思议，也是真相所在。所以原因应该就是，集合内的元素是真的不一样。
4.1 我的实体类即集合内的元素，是使用Lombok管理的：

@Data
public class Node {
private String a;
......
}

除了一个@Data注解内部只有声明的属性，@Data注解:注解在类上；提供类所有属性的 getting 和 setting 方法，此外还提供了equals、canEqual、hashCode、toString 方法。所以我的实体类是有equals方法的，也是比较两个对象的值，而不是地址值，所以toString 都是一样的，为啥equals方法不一样呢。

问题的解决

1. 解决问题的最有效的方法还是debug运行代码，一步一步看，但可能有些同学，只想debug看自己的实现，而忘了引用的别人的代码是如何的，这是不全面的。
2. 我debug整个测试代码，主要debug，assertEquals这个方法内部的逻辑，最终到了实体的equals方法，因为是注解，所以没法看实现过程，但是依然还是可以继续debug，使用进入方法的那个键,会发现使用lombok注解实现的equals方法，其实就是比较与另外一个对象相同属性的值是否相同，只要相同就会继续比较下一个，知道有不同的或者比较完，当我debug走到要Date createTime这个属性的时候,发现，不往下比较了，直接就结束了。
3. 很明显了，就是两个对象的createTime属性不相同，查看Date类的equals方法和toString方法

//equals方法
 public boolean equals(Object obj) {
        return obj instanceof Date && getTime() == ((Date) obj).getTime();
    }
//toString方法
public String toString() {
        // "EEE MMM dd HH:mm:ss zzz yyyy";
        BaseCalendar.Date date = normalize();
        StringBuilder sb = new StringBuilder(28);
        int index = date.getDayOfWeek();
        if (index == BaseCalendar.SUNDAY) {
            index = 8;
        }
        convertToAbbr(sb, wtb[index]).append(' ');                        // EEE
        convertToAbbr(sb, wtb[date.getMonth() - 1 + 2 + 7]).append(' ');  // MMM
        CalendarUtils.sprintf0d(sb, date.getDayOfMonth(), 2).append(' '); // dd

        CalendarUtils.sprintf0d(sb, date.getHours(), 2).append(':');   // HH
        CalendarUtils.sprintf0d(sb, date.getMinutes(), 2).append(':'); // mm
        CalendarUtils.sprintf0d(sb, date.getSeconds(), 2).append(' '); // ss
        TimeZone zi = date.getZone();
        if (zi != null) {
            sb.append(zi.getDisplayName(date.isDaylightTime(), TimeZone.SHORT, Locale.US)); // zzz
        } else {
            sb.append("GMT");
        }
        sb.append(' ').append(date.getYear());  // yyyy
        return sb.toString();
    }

如上所示Date比较不同是根据时间戳来对比，精确到毫秒，toString是输出，周，月，日，时分秒，时区，年；精确到秒，
所以即便输出的字符串是相同的，两个Date对象也不一定相同。
4. 重新Debug着重查看集合中的元素的创建时间属性，果然发现，两个元素的时间戳有着3毫秒的差别，所以导致字符串输出相同，但值却不同，这个坑踩了半天。

解决方法

修改类的equals方法

1. 因为是lombok管理实体类的方法，可以使用lombok的注解解决，在类上加上@EqualsAndHashCode(exclude = “createTime”),表示在equals方法和生成HashCode的时候排除createTime 属性。
2. 如果直接排除这个属性会影响业务逻辑，那就自己重写equals方法，自定义比较的规则，避开Date的坑，我就是自己重新定义equals方法

//直接比较字符串是否相等
	@Override
    public boolean equals(Object obj) {
    
        return  obj != null && (this.toString().equals(obj.toString()))
    }

总结

这个坑包含了，equals这个方法的坑，Date类的坑，以及lombok的坑，希望在以后的使用中能避开这些坑，如果你也进遇到了类似的问题，希望这篇文章能帮助到你。