关于单元测试和集成测试的新的理解

之前写了一篇关于对单元测试与集成测试的理解的文章，但过于泛泛。和朋友又讨论了下，从另外一个角度有了一点新的认识，记录一下。

先来段伪代码

(假设spring项目,规范格式-阿里巴巴,用的领域设计，Activity与User用Id软关联),业务不一定合理，只是用作演示。

• UserServiceImpl 用户的应用层
• UserRepository 用户仓储
• UserDO 用户的数据载体
• User 用户实体

@Servicepublic class UserServiceImpl {    @Resource    UserRepository userRepository;    @Resource    ActivityRepository activityRepository;    @Resource    MapperFactory mapperFactory;    /**     * 查询参加了活动的用户列表     */    public List<UserDO> queryUserOfActivity(Integer activityId) {        if (Objects.isNull(activityId)) {            throw 活动ID不能为空。        }        //查询活动        Optional<Activity> activityOption = activityRepository.getActivity(activityId);        //活动为空，抛自定义异常        Activity activity = activityOption.orElseThrow(NullActivityException::new);        //获取参加的用户Id        List<Integer> userIds = activity.getJoinUserIds();        List<Users> userList = userRepository.getUserListByIds(userIds);        List<UserDO> users = mapperFactory.getMapperFacade()                            .mapAsList(userList,UserDO.class);        return users;    }}

单元测试

针对以上代码做单元测试的话，就是只测试该方法中所书写的流程，其中的activityRepository.getActivity(activityId)与userRepository.getUserListByIds(userIds)都不算作是该单元本身的方法。

也就是说Mock两个假对象，让activityRepository.getActivity(activityId)与userRepository.getUserListByIds(userIds)都返回固定的结果，确保queryUserOfActivity方法调用的所有API都不会出错，这样错误只会出现在方法本身的代码，这样我觉得也可以称之为单元测试。

集成测试

如果能理解上面所说的单元测试，那么集成测试其实也就很好理解了。逐个放开上面单元测试中mock的假对象，这样就是多个方法集成到一起测试了。扩展一下，如果activityRepository和userRepository中也有其他类的API,那么就有两种集成测试的方法:

1. 横向:先逐个放开Userservice中的activityRepository 和 userRepository ，然后放开activityRepository和Userrepository中的其他类API
2. 纵向：先放开actityRepository,在放开activityRepository中其他类的APi，再放开userRepository中其他类的APi。

对应的就是自顶而下和自底而上两种测试方法。

实际项目中，这么做会很耗时，一般会把一整条分支全部放开来测试。