黄瓜养殖基地！

MouMock

发表于

MouMock (哞~ mock) 是我21年开发的一个Spring环境下的mock规约框架. 这个工具在规约和整理方向的意义比较大, 用于解决单测mock实例和mock数据混乱的问题

从上手使用例子开始看, 实际上推给同事也是这么推的
假如说我们现在有一个类DataApi, 是一个数据中台的api, 线上环境是需要rpc调用的, 但线下单测环境就需要mock, 这时候用MouMock的写法是这样的

1
2
3
4
5
6
7
8
9
10
11
12
13
// 业务代码中使用DataAPi的类
public class BlogService {
    @Autowired
    DataApi dataApi;
    
    public Blog getBlog(Long blogId) {
        // 从数据库获得这个blog的基本信息
        Blog blog = db.get(...);

        blog.visit = dataApi.queryData(blogId);
        return blog;
    }
}
1
2
3
4
5
6
7
8
9
// 单测的代码包里, 弄这样一个MouMock的类
@Configuration
public class DataApiMock extends MockBeanFactory<DataApi> { // 这里的MockBeanFactory就是MouMock提供的
    // 在这个类里写上一堆 mockForXXX方法, 针对各种场景构造不同数据
    // 构造mock数据的代码不允许写在这个类之外的地方, 只能存在于这个类里  
    public void mockForXXX {
        Mockito.when(getMockBean().queryData(Mockito.any())).thenReturn(...)
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// 实际的单测的代码
@SpringBootTest
public class BlogServiceTest {
    @Autowired
    DataApiMock dataApiMock;

    @Autowired
    BlogService blogService;

    @BeforeEach
    public void init() {
        dataApiMock.mockForBlog()
    }

    @Test
    public void testGetBlog() {
        Blog blog = blogService.getBlog(123L);
        // 这里会打印出 DataApiMock里造的数据
        print(blog.visit)
    }
}

这样写有几个好处:

  1. 对于每个类, 只能有一个属于它的MouMock的MockBeanFactory类, 并且这个MouMock创建出来的mockBean是优先于其他所有的mockBean的, 强制使用MouMock的MockBean, 使之前散落到各处的 造mock数据的代码, 集中在一个文件里, 代码结构更加规整
  2. 在写每个单测方法前, 要调用需要使用到的MockBeanFactory的想用的mock方法, 消灭 “诶我这个mock的数据不知道是在哪造出来的” 的情况

这个工具不足的地方:

  1. 目前限制了只能是Mockito的mock, 无法用其他mock框架
  2. MockBeanFactory这个名字取的不好…
  3. 公司团队内部使用, 没有开源…

上面两点好处在同事之间获得大片好评的, 很大程度上解决了先前mock混乱的问题