Mock不是测试的银弹

开发者编写高质量测试的征途上可谓布满荆棘,数据库、中间件、不同的文件系统等复杂外部系统的存在,令开发者在编写、运行测试时觉得苦恼异常。由于外部系 统常常运行在不同机器上或者本地单独的进程中,开发者很难在测试中操作和控制它们。外部系统以及网络连接的不稳定性(外部系统停止响应或者网络连接超 时),将有可能导致测试运行过程随机失败。另外,外部系统缓慢的响应速度(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
外部
微服务不是银弹、不是银弹、mock测试、java mock测试、spring mock 测试,以便于您获取更多的相关知识。

时间: 2024-10-26 05:37:36

Mock不是测试的银弹的相关文章

利用Spring2.5和Reflection简化测试中的mock

spring2.5最大的特色就是全面使用annotation代替xml配置,包括IOC Container.springMVC和 TestContext测试框架等,给我们开发带来了极大的便利.springMVC的新特性在这篇文章里面已经有了比较详尽的介绍,而对于spring的新TestContext测试框架,大家也可以从这里得到详细的例子说明,有兴趣的可以去仔细阅读,本文不再赘述.总而言之,通过spring2.5提供的 annotation,我们可以让我们的类--包括controller,Tes

如何让测试少加班?阿里Mock平台使用方法揭秘!

导读:作为一名测试,我们知道不是任何情况都可以用真实对象来测,比如我们要测一个地方PM2.5超过900的情况,我们不能每天等着PM2.5的指数超过900再测试,这个时候可以用一个虚拟对象来创建测试,做一个Mock.如何构造Mock使用场景?如何使用Mock提效,不用老加班?11月2日,阿里巴巴研发效能事业部-云效平台技术专家孙琛,在云效Work Like Alibaba系列直播上,结合视频演示为大家分享了Mock平台的功能实践,让大家在测试开发过程中用Mock提效. 为什么会需要Mock? 传统

mock 测试

mock测试 目录 概述 mock对象实例 mock- 展开 概述 mock对象实例 mock- 展开 编辑本段概述:http://baike.baidu.com/view/2445748.htm mock测试 就是在测试过程中,对于某些不容易构造或者 不容易获取的对象,用一个虚拟的对象来创建以便测试的测试方法. mock对象 这个虚拟的对象就是mock对象.mock对象就是真实对象在调试期间的代替品. mock对象使用范畴 真实对象具有不可确定的行为,产生不可预测的效果,(如:股票行情,天气预

Android测试教程(10):ActivityInstrumentationTestCase2示例

ActivityInstrumentationTestCase2 主要用来测试一个或多个Activity的功能测试,使用和最终应用同样的运行环境来测试 Activity的功能.可以使用正常系统Context (非Mock)来测试Activity的功能. 并允许你创建一些Mock Intent 用来测试 Activity的响应.要注意的是,这种TestCase不允许使用Mock的Context和Application对象测试,也就是说你必须使用和应用程 序实际运行的环境来测试. ActivityI

Android测试教程(6):测试Activity

Activity的测试非常依赖于Android的Instrumation 框架,和Android其他组件不同的是,Activity具有复杂的生命周期回调 函数(如onCreate, onStart 等) ,通常情况下除通过Instrumation 接口外不能直接调用这些回调函数. 测试Activity的基本测试类为InstrumentationTestCase,它提供了Instrumentation接口给TestCase的子类. 为了支持 Activity测试,InstrumentationTe

使用EasyMock更轻松地进行测试

用开放源码 mock 对象框架模拟接口.类和异常 测试驱动开发是软件开发的重要部分.如果代码不进行测试,就是不可靠的.所有代码都必须测试,而且理想情况下应该在编写代码之前编写测试.但是,有些东西容易测试,有些东西不容易.如果要编写一个代表货币值的简单的类,那么很容易测试把 $1.23 和 $2.8 相加是否能够得出 $4.03,而不是 $3.03 或 $4.029999998.测试是否不会出现 $7.465 这样的货币值也不太困难.但是,如何测试把 $7.50 转换为 €5.88 的方法呢(尤其

阿里云移动测试平台MQC移动测试沙龙第3期【北京站】

阿里云移动测试平台MQC移动测试沙龙 第3期[北京站] 11月25日,阿里云移动测试平台MQC将在阿里北京大本营举办移动测试第3期线下沙龙活动.本次沙龙由MQC发起,联合美团点评技术团队合办,旨在分享阿里云和美团内部移动测试技术干货.欢迎大家踊跃报名! 活动日期: 2017年11月25日 星期六 14:00-17:30 活动地点: 阿里中心.望京A座 5F-14岳麓书院 北京市朝阳区望京东园四区绿地中心 阿里中心.望京A座5层 活动主题: <详解阿里云测试专有云输出形态>.<移动时代后台

《有效的单元测试》一3.3 使用测试替身的指南

3.3 使用测试替身的指南 测试替身是程序员的工具,就像木匠的锤子和钉子.存在敲钉子的适当方式,当然也有不恰当的方式--最好是能把它们识别出来. 先从我认为最重要的指南开始吧,当你求助于测试替身时要时刻牢记它--从你的工具箱中选择合适的工具. 3.3.1 为测试挑选合适的替身 有许多测试替身可供选择,它们看起来各有千秋.采用它们的最佳条件是什么?到底应该选择哪个? 这里并没有太多的硬性规定,但一般来说你应该因地制宜地混合使用.我是说,某些情况下你只想要"一个返回5的对象",而其他情况下

《Spring官方文档》第三部分 测试9-10章节

作为 Spring 的开发团队,我们鼓励在开发活动中引入测试驱动开发(TDD,Test-Driveng-Development)的行为,因此本文档接下来将涵盖 Spring 框架对集成测试的支持(以及 Spring 下单元测试的最佳实践). Spring 开发团队发现对控制反转(IoC)的正确运用可以使针对代码编写单元测试与集成测试变得更为容易(setter方法的存在,以及类里面恰当的构造器,使得测试代码在无需类似服务工厂等辅助工具的前提下,也能够方便地对各个类进行调用).我们希望通过整整一章对