使用ArgumentCaptor时对象属性后修改导致的误报及测试策略

嘿，这个问题我之前踩过坑！核心原因是Java的引用传递特性——你在业务代码里先save了对象，之后又修改了它的属性，但ArgumentCaptor捕获的是同一个对象引用，所以测试验证时拿到的是修改后的值，可实际数据库里存的是修改前的状态。下面是具体的分析和解决方案：

为什么当前测试会“假通过”？ #

先理清楚业务代码的执行顺序：

1. 从DAO加载myObj（此时myInt=0）
2. 调用myDao.save(myObj)——这时候存的是myInt=0的对象
3. 把myObj.myInt改成1

但因为Java是引用传递，ArgumentCaptor.capture()拿到的是myObj的内存引用。当测试走到then阶段验证时，这个对象的属性已经被改成1了，所以断言is(1)会通过，但实际save的是0。

用eq(expected)也会踩同样的坑：如果MyDomainClass没重写equals，eq比较的是引用（肯定匹配）；如果重写了，验证时对象属性已经变了，eq也会误判为匹配。

如何修改测试来暴露这个bug？ #

方案一：捕获save瞬间的对象快照 #

最直接的办法是在save方法被调用的瞬间，对传入的对象做一个深拷贝（快照），这样后续修改原对象不会影响捕获到的状态。

首先给你的领域类加个快照方法（如果有复杂属性，要做深拷贝）：

public class MyDomainClass {
    public int myInt;
    
    // 保存当前状态的副本
    public MyDomainClass takeSnapshot() {
        MyDomainClass snapshot = new MyDomainClass();
        snapshot.myInt = this.myInt;
        // 其他属性也要逐一拷贝
        return snapshot;
    }
}

然后在测试里用Mockito的Answer来捕获快照，代替ArgumentCaptor：

@Test
public void testMyMethod() {
    // given
    MyDomainClass myObj = new MyDomainClass();
    when(myDao.load(anyInt())).thenReturn(myObj);
    
    // 用Answer捕获save时的对象快照
    final MyDomainClass[] savedSnapshot = new MyDomainClass[1];
    doAnswer(invocation -> {
        MyDomainClass arg = invocation.getArgument(0);
        savedSnapshot[0] = arg.takeSnapshot(); // 保存调用瞬间的状态
        return null;
    }).when(myDao).save(any(MyDomainClass.class));
    
    // when
    myApp.myMethod();
    
    // then
    assertThat(savedSnapshot[0].myInt, is(0)); // 这里会失败，直接暴露bug！
}

方案二：验证方法调用顺序（辅助排查） #

如果你的业务逻辑应该是先修改属性再save，那还可以用InOrder验证调用顺序，从另一个维度发现问题：

@Test
public void testMyMethodOrder() {
    // given
    MyDomainClass myObj = new MyDomainClass();
    when(myDao.load(anyInt())).thenReturn(myObj);
    
    // when
    myApp.myMethod();
    
    // then
    InOrder inOrder = inOrder(myDao);
    inOrder.verify(myDao).load(0);
    // 如果业务逻辑正确，这里应该先看到属性修改，再看到save调用
    // 但当前代码是先save再修改，所以这个测试会失败
    inOrder.verify(myDao).save(any(MyDomainClass.class));
}

ArgumentCaptor的适用场景与局限性 #

ArgumentCaptor不是万能的，它适合这些场景：

• 方法调用后，对象不会被后续代码修改；
• 捕获的是不可变对象（比如String、Integer），因为不可变对象的状态不会被改变。

但如果是可变对象且调用后会被修改，ArgumentCaptor就会出现这种误判——因为它抓的是引用，不是调用瞬间的状态快照。

更健壮的单元测试策略 #

除了上面的方案，还有两个长期优化方向：

1. 使用不可变领域对象：把领域类设计成不可变（属性用final，修改属性时返回新对象），这样后续修改不会影响之前的状态，测试也不会踩引用的坑；
2. 测试行为而非仅状态：不要只验证save的参数，还要验证业务逻辑的行为是否符合预期——比如调用顺序、次数等，这样能更全面地覆盖业务逻辑的正确性。

内容的提问来源于stack exchange，提问作者Stefan Berger