Android单元测试：如何验证私有Listener的方法调用状态

之前看到的方案是通过注入外部Listener，然后Mock这个实例来验证方法调用，但我的场景中，Listener是对象内部创建的私有实例，仅提供获取Listener的API，没有注入入口。比如下面的EventMonitor类：

class EventMonitor {
    public interface IEventListener {
        void onFirst(int value);
        void onSecond(int value1,int value2);
    };
    private IEventListener mEventListener = new IEventListener() {
        @Override
        public void onFirst(int value) {
            //dofirst
        }

        @Override
        public void onSecond(int value1, int value2) {
            //doSecond
        }
    };

    public IEventListener getEventListener(IEventListener listener) {
        return mEventListener;
    }

    public void doStuff() {
        mEventListener.onFirst(0);
        mEventListener.onSecond(1,1);
    }
}

怎么验证doStuff()调用后，onFirst和onSecond方法确实被执行了？

方案1：通过反射获取私有Listener并Spy验证 #

利用Java反射机制获取私有字段mEventListener，然后用Mockito的spy包装原始实例，捕获方法调用行为：

测试代码（JUnit + Mockito + PowerMock） #

import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.Mockito;
import org.powermock.api.mockito.PowerMockito;
import org.powermock.core.classloader.annotations.PrepareForTest;
import org.powermock.modules.junit4.PowerMockRunner;
import java.lang.reflect.Field;

@RunWith(PowerMockRunner.class)
@PrepareForTest(EventMonitor.class)
public class EventMonitorTest {

    @Test
    public void testDoStuffTriggersListenerMethods() throws Exception {
        EventMonitor monitor = new EventMonitor();
        
        // 反射获取私有字段，设置为可访问
        Field listenerField = EventMonitor.class.getDeclaredField("mEventListener");
        listenerField.setAccessible(true);
        EventMonitor.IEventListener originalListener = (EventMonitor.IEventListener) listenerField.get(monitor);
        
        // Spy原始Listener，用于捕获调用行为
        EventMonitor.IEventListener spiedListener = Mockito.spy(originalListener);
        // 将Spy实例替换回对象中的私有字段
        listenerField.set(monitor, spiedListener);
        
        // 触发目标方法
        monitor.doStuff();
        
        // 验证方法调用次数和参数
        Mockito.verify(spiedListener).onFirst(0);
        Mockito.verify(spiedListener).onSecond(1, 1);
    }
}

优缺点 #

• 优点：不需要修改原有业务代码，直接适配现有实现
• 缺点：依赖反射，字段名或访问权限变更会导致测试失败；代码相对繁琐，可读性较差

方案2：调整代码设计，支持测试注入 #

如果允许修改业务代码，最佳实践是给EventMonitor添加一个支持注入Listener的构造函数（或包级别的setter），默认使用内部实现，测试时注入Mock实例：

修改后的EventMonitor代码 #

class EventMonitor {
    public interface IEventListener {
        void onFirst(int value);
        void onSecond(int value1,int value2);
    };

    private IEventListener mEventListener;

    // 默认构造：使用内部Listener实现
    public EventMonitor() {
        this.mEventListener = new IEventListener() {
            @Override
            public void onFirst(int value) {
                //dofirst
            }

            @Override
            public void onSecond(int value1, int value2) {
                //doSecond
            }
        };
    }

    // 测试专用构造：允许注入自定义Listener
    EventMonitor(IEventListener listener) {
        this.mEventListener = listener;
    }

    public IEventListener getEventListener() {
        return mEventListener;
    }

    public void doStuff() {
        mEventListener.onFirst(0);
        mEventListener.onSecond(1,1);
    }
}

测试代码（JUnit + Mockito） #

import org.junit.Test;
import org.mockito.Mockito;

public class EventMonitorTest {

    @Test
    public void testDoStuffCallsListenerMethods() {
        // 创建Mock的Listener实例
        EventMonitor.IEventListener mockListener = Mockito.mock(EventMonitor.IEventListener.class);
        // 注入Mock实例创建EventMonitor
        EventMonitor monitor = new EventMonitor(mockListener);
        
        // 触发目标方法
        monitor.doStuff();
        
        // 直接验证Mock的方法调用
        Mockito.verify(mockListener).onFirst(0);
        Mockito.verify(mockListener).onSecond(1, 1);
    }
}

优缺点 #

• 优点：测试代码简洁直观，符合测试友好的设计原则，后续维护成本低
• 缺点：需要修改原有业务代码，若代码处于已上线的稳定阶段，可能需要评估改动影响

方案3：验证Listener方法的副作用（间接测试） #

如果onFirst或onSecond方法有可观测的业务副作用（比如修改了某个公共状态、触发了其他可验证的行为），可以通过验证这些副作用来间接判断方法是否被调用。但这种方法仅适用于有明确外部效果的场景，通用性较差。

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