首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >TW洞见 | 胡凯:Mock不是测试的银弹

TW洞见 | 胡凯:Mock不是测试的银弹

作者头像
ThoughtWorks
发布2018-04-20 15:14:58
1.8K0
发布2018-04-20 15:14:58
举报
文章被收录于专栏:ThoughtWorksThoughtWorks

开发者编写高质量测试的征途上可谓布满荆棘,数据库、中间件、不同的文件系统等复杂外部系统的存在,令开发者在编写、运行测试时觉得苦恼异常。由于外部系 统常常运行在不同机器上或者本地单独的进程中,开发者很难在测试中操作和控制它们。外部系统以及网络连接的不稳定性(外部系统停止响应或者网络连接超 时),将有可能导致测试运行过程随机失败。另外,外部系统缓慢的响应速度(HTTP访问、启动服务、创建删除文件等),还可能会造成测试运行时间过长、成 本过高。种种问题使开发者不断寻找一种更廉价的方式来进行测试,mock便是开发人员解决上述问题时祭出的法宝。mock对象运行在本地完全可控环境内,利用mock对象模拟被依赖的资源,使开发者可以轻易的创建一个稳定的测试环境。mock对象本地创建,本地运行的特性更是加快测试的不二法门。

我所在团队设计开发的产品是持续集成服务器,产品特性决定了它需要在各个平台(Windows, Mac, Linux等)与各种版本管理工具(svn, mercurial,git等)、构建工具(ant, nant, rake等)进行集成,对于外部系统的严重依赖让我们在编写测试时遇到了很多困难,我们自然而然的选用了JMock作为测试框架,利用它来隔离外部系统对 于测试的影响,的的确确在使用JMock框架后测试编写起来更容易,运行速度更快,也更稳定,然而出乎意料的是产品质量并没有如我们所预期的随着不断添加 的测试而变得愈加健壮,虽然产品代码的单元测试覆盖率超过了80%,然而在发布前进行全面测试时,常常发现严重的功能缺陷而不得不一轮轮的修复缺陷、回归 测试。为什么编写了大量的测试还会频繁出现这些问题呢? 在讨论之前先来看一个真实的例子:

我们的产品需要与Perforce(一种版本管理工具)进行集成,检测某段时间内Perforce服务器上是否存在更新,如果有,将更新解析为 Modification对象。将这个需求反应在代码中,便是首先通过Perforce对象检测服务器更新,然后将标准输出(stdout)进行解析:

public class PerforceMaterial {
    private Perforce perforce;
    .....
    .....
    public List findModifications(Date start, Date end) {
        String changes = perforce.changes(start, end);    //检测更新,返回命令行标准输出(stdout)        
        List modifications = parseChanges(changes);//将标准输出解析为Modification
        return modifications;
    }

    private List parseChanges(String output) {
         //通过正则表达式将stdout解析为Modification对象
    }
}

public class Perforce {
    public String changes(Date start, Date end) {
          //通过命令行检测更新,将命令行标准输出(stdout)返回
    }
}             



相应的mock测试也非常容易理解:


    .....
    .....  
    @Test
    public void shouldCreateModifiationWhenChangesAreFound() {
        final String stdout = "Chang 4 on 2008/09/01 by p4user@Dev01 'Added build.xml'"; //设置标准输出样本
        final Date start = new Date();
        final Date end = new Date();

        context.checking(new Expectations() {{
            one(perforce).changes(start, end);
            will(returnValue(stdout));
        }});//设置perforce对象的行为,令其返回设定好的stdout

        List list = perforceMaterial.findModifications(start, end);//调用被测方法

        assertThat(list.get(0).revision(), is("4"));
        assertThat(list.get(0).user(), is("p4user@Dev01"));
        assertThat(list.get(0).modifiedTime(), is("2008/09/01"));
}  

测试中的stdout是在真实环境下运行Perforce命令行所采集的标准输出(stdout)样本, 通过mock perforce对象,我们可以轻易的控制changes方法的返回值,让验证解析逻辑的正确性变得非常容易,采用mock技术使开发者无需顾忌 Perforce服务器的存在与否,而且可以采用不同的stdout来覆盖不同的情况。然而危机就在这看似完美的测试过程中被埋下了,事实上 Perforce stdout中的时间格式会依用户环境的设定而变化,从而进一步导致parseChanges方法中的解析逻辑出现异常。由于测试中的stdout全由假 设得来,并不会依照环境变化,即便我们将测试跑在多种不同的环境中也没能发现问题,最终在产品环境才由客户发现并报告了这个缺陷。

真实perforce对象的行为与测试所使用的mock对象行为不一致是出现上述问题的根本原因,被模拟对象的行为与真实对象的行为必须完全一致称之为mock对象的行为依赖风险。 开发者对API的了解不够、被模拟对象的行为发生变化(重构、添加新功能等修改等都可能引起被被模拟对象的行为变化)都可能导致错误假设(与真实对象行为 不一致),错误假设会悄无声息的引入缺陷并留下非法测试。非法测试在这里所代表的含义是,它看起来很像测试,它运行起来很像测试,它几乎没有价值,它几乎 不会失败。在开发中,规避行为依赖风险最常见的方法是编写功能测试,由于在进行mock测试时,开发者在层与层之间不断做出假设,而端到端的功能测试由于 贯穿了所有层,可以验证开发者是否做出了正确的假设,然而由于功能测试编写复杂、运行速度慢、维护难度高,大部分产品的功能测试都非常有限。那些通过 mock测试的逻辑,便如埋下的一颗颗定时炸弹,如何能叫人安心的发布产品呢?

《UNIX编程艺术》中有一句话“先求运行,再求正确,最后求快”,正确运行的测试是高质量、可以快速运行测试的基础,离开了正确性,速度和隔离性都是无 根之木,无源之水。那么采用真实环境就意味着必须承受脆弱而缓慢的测试么?经历了一段时间的摸索,这个问题的答案渐渐清晰起来了,真实环境的测试之所以痛 苦,很大程度上是由于我们在多进程、多线程的环境下对编写测试没有经验,不了解如何合理的使用资源(所谓的资源可能是文件、数据库中的记录、也可能是一个 新的进程等),对于我们,mock测试作为“银弹”的作用更多的体现在通过屏蔽运行在单独进程或者线程中的资源,将测试简化为对大脑友好的单线程运行环境。在修复过足够多的脆弱测试后,我们发现了编写健壮测试的秘密:

要设计合理的等待策略来保守的使用外部系统。很多情况下,外部系统处于某种特定的状态是测试得以通过的条件,譬如HTTP服务必须启动完 毕,某个文件必须存在等。在编写测试时,开发者常常对外部系统的估计过于乐观,认为外部系统可以迅速处于就绪状态,而运行时由于机器和环境的差异,结果往 往不如开发者所愿,为了确保测试的稳定性,一定要设计合理的等待策略保证外部系统处于所需状态,之所以使用"等待策略"这个词,是因为最常见”保证外部系 统处于所需状态“的方法是万恶的"Thread.sleep", 当测试运行在运算速度/网络连接速度差异较大的机器上时,它会引起随机失败。而比较合理的方法是利用轮询的方式查看外部系统是否处于所需状态(譬如某个文 件存在、端口打开等),只有当状态满足时,才运行测试或者进行Assertion,为了避免进入无限等待的状态,还应该设计合理的timeout策略,帮 助确定测试失败的原因。

要正确的创建和销毁资源漠视测试环境的清理也常常是产生脆弱测试的原因,它主要表现在测试之间互相影响,测试只有按照某种顺序运行时才会成功/失败,这种问题一旦出现会变的非常棘手,开发者必须逐一对有嫌疑的测试运行并分析。因此,有必要在开始时就处理好资源的创建和销毁,使用资源时应当本着这样一个原则:谁创建,谁销毁。 junit在环境清理方面所提供的支持有它的局限性,下面的代码是使用资源最普遍的方式:

@After
public void teardown() {
   //销毁资源A
   //销毁资源B
}

@Test
public void test1() {
   //创建资源A
}

@Test
public void test2() {
   //创建资源B

}

为了确保资源A与资源B被正确销毁,开发者必须将销毁资源的逻辑写在teardown方法中,然而运行用例test1时,资源B并未被创建,所以必须在 teardown中同时处理资源A或B没有被创建的情况,由于需要销毁的资源是用例中所使用资源的并集,teardown方法会快速得膨胀。由于这样的原 因,我在开源项目junit-ext中加入了对Precondition的支持,在测试用例运行前,其利用标注所声明的多个Precondition的setup方法会被逐一调用来创建资源,而测试结束时则调用teardown方法销毁资源。

@Preconditions({ResourceIsCreated.class, ServiceIsStarted.class})
@Test
public void test1() {
      //在测试中使用资源
}

public class ResourceIsCreated implements Precondition {
    public void setup() {
           //创建资源
    }
    public void teardown() {
           //回收资源
    }
}

public class ServiceIsStarted implements Precondition {
     public void setup() {
           //创建资源
     }
     public void teardown() {
           //回收资源
     }
}

public interface Precondition {
     void setup();

     void teardown();

}

这个框架可以更好的规范资源的创建和销毁的过程,减少因为测试环境可能引起的随机失败,当然这个框架也有其局限性,在ResourceIsCreated 和ServiceIsStarted之间共享状态会比较复杂,在我们的产品中,Precondition大多用于启动新进程,对于共享状态的要求比较低, 这样一套机制就非常适合。每个项目都有其特殊性,面对的困难和解决方案也不尽相同,但在使用资源时如果能遵守“谁创建,谁销毁”的原则,将会大大减小测试 之间的依赖性,减少脆弱的测试。

要设计合理的过滤策略来忽略某些测试。我们很容易在项目中发现只能在特定环境下通过的测试,这个特定环境可能是特定的操作系统,也可能是特 定的浏览器等,之所以会产生这些测试通常是开发者需要在源码中进行一些特定环境的hack,它们并不适合在所有环境下运行,也无法在所有环境中稳定的通 过,因此应该设计一套机制可以有选择的运行这些测试,junit的assumeThat的机制让我再次有点失望,本着自己动手丰衣足食的原则,在junit-ext我添加了利用标注来过滤测试的机制,标注了RunIf的测试仅当条件满足时才会运行,除了内置一些Checker,开发者也可以很方便的开发自己的Checker来适应项目的需要。

  @RunWith(JunitExtRunner.class)
  public class Tests {
    @Test
    @RunIf(PlatformIsWindows.class) //test1仅运行在Windows环境下
    public void test1() {
    }
}

public class PlatformIsWindows implements Checker {
    public boolean satisfy() {
        //检测是否WINDOWS平台
    }

}

要充分利用计算资源而不是人力资源来加快测试。对于加快测试,最普遍也最脆弱的方法是利用多线程来同时运行多个测试,这个方法之所以脆弱, 是因为它会让编写测试/分析失败测试变的异常复杂,开发者必须考虑到当前线程在使用资源时,可能有另一个线程正要销毁同一个资源,而测试失败时,也会由于 线程的不确定性,导致问题难于重现而增加了解决问题的成本。我认为一个更好的实践是在多台机器上并发运行测试,每台机器只需要运行(总测试数/机器数)个 测试,这样所花费时间会近似减少为(原本测试时间/机器数)。相对与购置机器的一次性投入,手工优化的不断投入成本更高,而且很多公司都会有闲置的计算资 源,利用旧机器或者在多核的机器上安装虚拟机的方式,可以很经济的增加计算资源。在项目开发的业余时间,我和我的同事们一起开发了开源的测试辅助工具test-load-balancer。在我们的项目中,通过它将需要90分钟的测试自动划分为数个10分钟左右的测试在多台虚拟机上并发运行,很好的解决了速度问题。

对mock追本溯源,我们会发现它更多扮演的是设计工具的角色而不是测试工具的角色,mock框架在设计方面的局限性李晓在《不要把Mock当作你的设计利器》一文中已经谈的很透彻,在此不再赘述。Mock不是测试的银弹,世上也并无银弹存在,测试实践能否正常开展的决定性因素是团队成员对测试流程,测试方法的不断改进而不是先进的测试框架。不要去依赖mock框架,它的强制约定常常是你改进设计和添加功能的绊脚石,改善设计,依赖一个简洁的代码环境,依赖一套可靠的测试方法才是正途。从意识到mock测试带来的负面影响,到从滥用mock的泥潭中挣扎出来,我们花费了很多时间和经历,希望这些经验可以对同行们能有所借鉴,有所启发。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2015-02-09,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 思特沃克 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
持续集成
CODING 持续集成(CODING Continuous Integration,CODING-CI)全面兼容 Jenkins 的持续集成服务,支持 Java、Python、NodeJS 等所有主流语言,并且支持 Docker 镜像的构建。图形化编排,高配集群多 Job 并行构建全面提速您的构建任务。支持主流的 Git 代码仓库,包括 CODING 代码托管、GitHub、GitLab 等。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档