基于hadoop的单元测试mock技术分享

小蜻蜓

引子

前一段时间，公直给大家培训Toast工具的使用，以及分享了单元测试的心得。其间提到的单元测试中经常用到的mock技术。这两天我尝试就Mock技术在hadoop上的使用做个例子，分享一下我的理解，希望能给开发和测试同学带来一些帮助。

为什么单元测试需要使用mock？我们先看看一个有意思的定义，根据《测试驱动开发的艺术》一书中的定义，在以下情况中一个测试不是单元测试：

• 访问了数据
• 有网络通讯
• 访问了文件系统
• 不与其他任何单元测试同时运行
• 必须配置好环境后才能运行
  

我们现实项目中常常遇到单元测试因为环境等各种外界因素频繁失效，因为依赖的类和方法变动频繁失效，检查和维护这些测试代码，让人非常烦躁。其实反过来看看上面的定义，我们会发现很多时候对单元测试的理解是有问题的，是与集成测试、系统测试简单划上了等号的。

单元测试的目的不在于集成，而在于以简洁有效的方式，对代码的逻辑进行快速的验证，通过测试代码不断推动开发工作的进行。这就很自然的需要使用mock技术来替换掉一些逻辑无关的依赖。尤其在多人协作开发的项目中，mock方法是提高项目效率的常见手段。

回到正题，hadoop的单元测试一直是个挑战。在不间断的google中，目前为止也没有找到一个特别合适的单元测试框架。

也因此我一直在思考hadoop之上的单元测试如何开展，在之前我的一封邮件中只是给出了个最简单的注入式mock的手段。但实际上，开发hadoop之上的单元测试代码，确实挑战不小，有些挑战是hadoop带来的，有些是被测代码的设计带来的。

这里我分享一下，使用Mockito（《hadoop权威指南》中mock工具包）+ PowerMock工具来做hadoop上一个头疼函数的单元测试。

首先看看被测代码

这次挑的是店铺搜索的ShopScanMap类：

public class ShopScanMap extends TableMapper<Text, Text> { @Override     public void setup(Context context) throws IOException {           //…        Configuration conf = context.getConfiguration();        ht_shop_info = new HTable(conf, Bytes.toBytes(ParaDefine.t_shop_info));        ht_bmw_users = new HTable(conf, Bytes.toBytes(ParaDefine.t_bmw_users));          …        count_bmw = context.getCounter("Statistics", ParaDefine.t_bmw_shops);          //… }     @Override     public void map(ImmutableBytesWritable inKey, Result inValue,            Context context) throws IOException, InterruptedException {          //调用main_process方法 } private int main_process(Map<String, String> mapOutPut,            Field_Bmw_Shops fBmwShops, long shop_id, TimeBill timeBill_shop,            TimeBill timeBill_user) throws IOException {          //…        Get gtShopInfo = new Get(r_shopinfo.getBytes());        Result rsShopInfo = ht_shop_info.get(gtShopInfo);          //… } ｝

上面是个基本代码框架，这次我挑了个硬骨头main_process方法来演示一下如何使用mock，也是该类的核心方法。为什么说是硬骨头，因为：

• 首先是个private方法
• 调main_process之前，框架自动调用setup方法根据上下文进行各种初始化，然后才启用map。为了不依赖外部环境，就必须mock上下文，mock setup过程。
• 在setup方法中，会初始化HTable对象，而这又需要连上对应zookeeper和hbase环境。所以又必须mock HTable类。
• 在setup方法中，还需要获取Configuration，这个又需要mock。
• 在setup方法中，还有该死的Counter，我之前尝试new，发现不对，构造函数是protected。所以在前面都mock的前提下，你又必须mock Counter类。
• 在main_process方法中，这里需要从HTable对象中拿到数据。因为前面mock了HTable类，所以这里还需要mock get方法，不然数据是拿不到的。
  

可能有人问，为什么不直接mock好Context对象，一次性搞定。实际上，我试过，但是Context对象的构造也是非常头疼的，而且很多类是无法简单mock，搞了半天后，我放弃了，还是用最笨的方式。后面我会再想办法尝试尝试。

再看看测试代码

下面一条条看如何mock，上测试代码。

• Private方法我是偷懒了，直接在源代码中注入了public int mainProcess方法，该方法只一句调用main_process，这样我能间接的获取该方法的调用。通过PowerMock是能够mock私有方法的，不过很多人不推荐，担心有隐患。
  

• 在使用powermock之前，需要在测试类前加入
  

@RunWith(PowerMockRunner.class) @PrepareForTest({ ShopScanMap.class }) public class TestMockito {     @Test     public void test01() throws Exception {…}

对setup方法涉及到的几个基本外部依赖类要进行mock

Mapper.Context context = mock(Mapper.Context.class);        Counter counter = mock(Counter.class);        Configuration config = mock(Configuration.class);

• 对HTable进行mock，然后初始化shop_info对象。接着对构造函数进行mock，在thenReturn中期望new之后返回的是mock后的HTable对象。PowerMockito的方法还是很好理解的，whenNew表示调用new方法时，withArguments表示构造函数的参数，thenReturn表示期望返回的值。
  

HTable shop_info = PowerMockito.mock(HTable.class);        PowerMockito.whenNew(HTable.class)               .withArguments(config, "sp_shopinfo".getBytes())               .thenReturn(shop_info);

• 因为setup方法中调用了getConfiguration来获取配置，所以必须mock，才能消除对外部配置的依赖
  

when(context.getConfiguration()).thenReturn(config);

• 原因同getConfiguration。不过不一样的是，这里需要带上模拟的参数。至于参数的值，我是从被测试代码中分析出的数据。
  

when(context.getCounter("Statistics", "sp_bmw_shops")).thenReturn(               counter);

• 最关键的需要从HTable中拿到数据，为此我需要Mock Get对象作为get方法的参数，同时需要构造我希望拿到的Result类型的数据。最后通过PowerMockito，when调用shop_info.get(gtShopInfo)这个HTable对象的方法时，期望thenReturn一个事先定义好的shop_info_result对象。
  

Get gtShopInfo = PowerMockito.mock(Get.class);        PowerMockito.whenNew(Get.class)               .withArguments("126:38934426".getBytes())               .thenReturn(gtShopInfo);        List<KeyValue> kv_shop_info = new ArrayList<KeyValue>();        kv_shop_info.add(new KeyValue("126:38934426".getBytes(), "sp_shop_info"               .getBytes(), "feature".getBytes()));        Result shop_info_result = new Result(kv_shop_info);        PowerMockito.when(shop_info.get(gtShopInfo)).thenReturn(               shop_info_result);

准备好所有的mock之后，ShopScanMap这里还需要准备一些测试数据，不过比较简单，就不多说了。

万事俱备后，就可以调用各种mock之后的main_process方法，拿到期望的结果

int r = map.mainProcess(mapOutPut, fBmwShops, shop_id, timeBill_shop,               timeBill_user);        /**        * 这里没做断言，只是输出返回值和mapOutPut的内容        */        System.out.println(r);        System.out.println(mapOutPut.toString());

个人感受：

         这里举的例子是很艰苦的，我做这个例子做的很吐血。由于我水平的有限，测试代码本身应该还有很大优化的空间。

实际上通过优化开发代码的设计，剥离出业务逻辑，使我们只关注核心业务逻辑，这样能够从另一方面大大降低单元测试的成本。比如ShopScanMap的do_seller, do_prepay等封装的就很好。

另外可以看出我动用了很多手段，才算完成这个mock工作。但是这个工作是重复性的，可以复用的价值很低。非常需要一整套基于hadoop之上的完整mock方案。我调研过mrunit和淘宝搞的ITest-hadoop。前者局限性比较大，而且太靠近map/reduce层面，对业务逻辑的关注力度不够，很不顺手；后者实际上是基于hadoop自带模拟集群的MiniDFSCluster, MiniMRCluster, MiniHBaseCluster三个类来实现的代码层面的集成测试，按照之前单元测试的定义，我不认为这是一种常规的单元测试方案，而且成本也挺高的。不过ITest-hadoop框架的优点是提供了一个在本地开发环境就能自测的完整方案，可以作为一个备用方案。

这里和大家分享分享一些UT的思路，希望大家抛砖，希望能够一起学习，共同进步。

附上POM的依赖

<dependency>            <groupId>org.mockito</groupId>            <artifactId>mockito-all</artifactId>            <version>1.8.5</version>        </dependency>        <dependency>            <groupId>org.powermock</groupId>            <artifactId>powermock-module-junit4</artifactId>            <version>1.4.10</version>        </dependency>        <dependency>            <groupId>org.powermock</groupId>            <artifactId>powermock-api-mockito</artifactId>            <version>1.4.10</version>        </dependency> 网上看到的，写的不错：http://testing.etao.com/node/668