单元测试可以提高测试开发的效率,减少代码错误率,提高代码健壮性,提高代码质量。在Spring框架中常用的两种测试框架:PowerMockRunner和SpringRunner两个单元测试,鉴于SpringRunner启动的一系列依赖和数据连接的问题,推荐使用PowerMockRunner,这样能有效的提高测试的效率,并且其提供的API能覆盖的场景广泛,使用方便,可谓是Java单元测试之模拟利器。
框架的选择大同小异。Junit4&Junit5的对比:《Junit4&Junit5对比》
前面讲了Spock框架Mock对象、方法经验总结,今天分享一下Spock框架中Mock静态资源的实践经验汇总。分成「静态资源」和「混合场景」。
充分的单元测试就是提高代码质量最有效的手段之一,而单元测试严重依赖代码的可测试性,本文主要通过一个简单的DEMO演示如何对Android原生应用进行单元测试,同时示例代码采用MVP模式以提高代码的可读性和可测试性
对于有经验的开发写单元测试是非常有必要的,并且对自己的代码质量以及编码能力也是有提高的。单元测试可以帮助减少bug泄露,通过运行单元测试可以直接测试各个功能的正确性,bug可以提前发现并解决,由于可以跟断点,所以能够比较快的定位问题,比泄露到生产环境再定位要代价小很多。同时充足的UT是保证重构正确性的有效手段,有了足够的UT防护,才能放开手脚大胆重构已有代码,工 作多年后更了解了UT,了解了UT的重要性。
目前应用比较普遍的java单元测试工具junit4+Mock(Mockito、jmock、EasyMock、powermock)。为什么会选powermock? 在做单元测试的时候,我们会发现我们要测试的方法会有很多外部依赖的对象或者一些其他服务的调用比如说(发送邮件,网络通讯,soa调用)。而我们没法控制这些外部依赖的对象。为了解决这个问题,我们需要用到Mock来模拟这些外部依赖的对象,从而控制它们。只关心我们自己的业务逻辑是否正确。而这时powermock就起作用了,它不仅可以mock外部的依赖,还可以mock私有方法、final方法,总之它的功能很强大。
当我们面对一个遗留系统时,常见的问题是没有测试。正如Michael Feathers在Working Effectively with Legacy Code一书中对“遗留代码”的定义。他将其简单归纳为“没有测试的代码”。真是太贴切了!正是因为没有测试,使得我们对遗留代码的任何重构都有些战战兢兢,甚至成为开发人员抵制重构的借口。从收益与成本的比例来看,对于这样的系统,我一贯认为不要盲目进行重构。因为重构的真正适用场景其实是发生在开发期间,而非维护期间。当然,提升自己的重构能力,尤其学会运用IDE提供的自动重构工具,可以在一定程度上保障重构的质量。然而,安全的做法,还是需要为其编写测试。
在Android Studio中新建一个项目的时候,app的gradle中会默认添加单元测试的相关依赖库:
Spock是国外一款优秀的测试框架,基于BDD(行为驱动开发)思想实现,功能非常强大。Spock结合Groovy动态语言的特点,提供了各种标签,并采用简单、通用、结构化的描述语言,让编写测试代码更加简洁、高效。目前,美团优选物流绝大部分后端服务已经采用了Spock作为测试框架,在开发效率、可读性和维护性方面均取得了不错的收益。
在单元测试中,我们往往想去独立地去测一个类中的某个方法,但是这个类可不是独立的,它会去调用一些其它类的方法和service,这也就导致了以下两个问题:外部服务可能无法在单元测试的环境中正常工作,因为它们可能需要访问数据库或者使用一些其它的外部系统。我们的测试关注点在于这个类的实现上,外部类的一些行为可能会影响到我们对本类的测试,那也就失去了我们进行单测的意义。
近期已然陷入了单元测试的汪洋大海,上万行的代码突然要求起来单元测试覆盖率,着实很恐怖的。最经过艰苦的抗争学习之后,终于迈过了技术这个坎儿,特来分享一下最近踩坑的经历,和一些典型的使用场景案例分享。
单元测试(Unit Testing),是指对软件或项目中最小可测试单元进行正确性检验的测试工作。单元是人为规定最小可测试的功能模块,可以是一个模块,一个函数或者一个类。单元测试需要与模块开发进行隔离情况下进行测试。
笔者最近参加了一系列校园招聘,问到同学们熟悉哪些设计模式时,基本上所有人都提到了单例模式。
mockito框架上手非常简单,但是它也有弊端和局限性,不能mock静态方法、私有方法、构造方法等,但powermockito框架很好的弥补了这一缺陷。
所以我们在单测中,往往会使用mock的方式对这些代码做一个数据的模拟,从而达到对代码进行测试的一个目的。
相信做过开发的同学,都多多少少写过下面的代码,很长一段时间我一直以为这就是单元测试...
MOCK意思是模拟的意思,主要被用来进行数据的人工组织,不会真正地调用第三方服务器,类似redis,mysql等都不会调用,也不用关心数据底层是如何进行处理的,我们要做的只是将本单元的逻辑进行单元测试,验证数据的逻辑处理性,而其中mock较好的框架就是Mockito。
笔者在对某个JAVA socket通信程序进行UT的时候,遇到过以下一个场景,客户端发出登陆请求,然后每隔500ms监查一下底层通信机的登陆状态,如果登陆成功,底层通信机会将其状态修改为LOGIN_SUCCESS/LOGIN_FAILED。客户端检查时如果发现登陆状态不是上述两个状态,则线程休眠500ms然后继续监查。上述逻辑要重复30次,也就是15秒后,如果登陆状态不是上述成功/失败的状态,则表示未收到登陆答复等逻辑,需要切换服务器继续登陆。
在TDD领域Mock框架有很多,比如EasyMock,JMock,Mockito。可能有些同学会好奇了,为什么要重点把PowerMock拿出来呢,因为PowerMock可以解决前面三种框架不能解决的问题,而且PowerMock也是是单元测试中极其强大的测试框架。
昨天天去github上的PowerMock 项目去看了一下。这个项目上次的commit和发布已经是10个月之前了。还积攒了400个问题和13个PR没有合并。当然,作为一个出道很久的小众Mock工具的项目,本身的活跃度低也是比较正常的。不过,很多Issue其实是关于新JDK兼容性的。从这点上看,维护者已经不是在积极维护这个项目了。
作者:刘洋 团队公众号:腾讯移动品质中心TMQ 一、单元测试及Android单元测试简介 惯例,先简单介绍下理论知识,懂得的可以跳过。 1、单元测试定义和特性 单测定义: 在计算机编程中,单元测试(U
在TDD领域Mock框架有很多,比如EasyMock,JMock,Mockito。可能有些同学会好奇了,为什么要重点把powermock拿出来呢,因为powermock可以解决前面三种框架不能解决的问题,而且powermock也是是单元测试中极其强大的测试框架。
现在流行的测试驱动开发TDD(Test-Driven Development) ,是敏捷开发中一项核心实践和技术。也是一种设计方法论。其中最重要的一环就是使用单元测试。单元测试是保证代码质量的一个重要手段,通过单元测试我们可以快速的测试代码的各个分支,各种场景,代码重构时只需要重新跑下单元测试就是能知道代码潜在的问题。单元测试是通过Mock的方式调用被测试的方法,其有如下几个优点:
单元测试(unit testing)是指对软件中的最小可测试单元进行检查和验证。它是软件测试中的一种基本方法,也是软件开发过程中的一个重要步骤。
大多数同事都用 JUnit 做单元测试,JUnit 中对方法调用打桩(Mock)是一个麻烦事。好在 EasyMock 可以帮我们完成。
单例模式指的是在应用整个生命周期内只能存在一个实例。单例模式是一种被广泛使用的设计模式。他有很多好处,能够避免实例对象的重复创建,减少创建实例的系统开销,节省内存。
Mock的概念,其实很简单:所谓的mock就是创建一个类的虚假的对象,在测试环境中,用来替换掉真实的对象,以达到两大目的:
这篇教程介绍了如何使用 Mockito 框架来给软件写测试用例。 1、预备知识 如果需要往下学习,你需要先理解 Junit 框架中的单元测试。 如果你不熟悉 JUnit,请查看下面的教程: http://www.vogella.com/tutorials/JUnit/article.html 2、使用mock对象来进行测试 2.1 单元测试的目标和挑战 单元测试的思路是在不涉及依赖关系的情况下测试代码(隔离性),所以测试代码与其他类或者系统的关系应该尽量被消除。一个可行的消除方法是替换掉依赖类(测试替换),
以上createInetSocketAddress方法就是我在编写单元测试的时候单独抽离出来的方法,一方面我需要mock一个InetSocketAddress来满足测试需求,另一方面,单独抽离一个createInetSocketAddress方法从代码上看也是必要的,让方法职责更加单一,如果把createInetSocketAddress的实现直接耦合到connectImpl方法中,那么connectImpl的代码除了连接tcp的逻辑外还有创建InetSocketAddress的逻辑,这样就比较混乱,而且方法体也变长
如果将mock单独翻译过来,其意义为 “虚假、虚设”,因此在软件开发领域,我们也可以将其理解成 “虚假数据”,或者 “真实数据的替身”。
TDD是测试驱动开发(Test-Driven Development)的英文简称,是敏捷开发中的一项核心实践和技术,也是一种设计方法论。TDD的原理是在开发功能代码之前,先编写单元测试用例代码,测试代码确定需要编写什么产品代码。TDD虽是敏捷方法的核心实践,但不只使用于XP(Extreme Programming),同样可以适用于其他开发方法和过程。 打桩(mock)是单元测试的重要内容。说难点,谈不上吧,能说出来想到的都不算是难点了。 mock有两种。一种是静态打桩,一种是动态打桩
spock是一款基于Groovy语言的单元测试框架,其基础也是Java的Junit,目前最新版已经到了2.0,但对Groovy和响应的Java版本要求较高,具体信息参考:Spock 2.0 M1版本初探。
单元测试(Android) 活动时间:2017年6月14日 斗鱼直播:http://www.douyu.com/TMQ 活动介绍:TMQ在线沙龙第二十二期分享 本次分享的主题是:单元测试(Android) 直播期间,有299位小伙伴在线观看! 想知道活动分享了啥吗, 请往下看吧! 活动嘉宾 嘉宾简介 刘洋,腾讯应用宝高级测试工程师,目前主要负责应用宝业务的代码分析、精准测试、工具建设等。在安卓客户端、后台类领域测试有比较丰富的经验。 分享主题 1、Android单元测试简介和意义 2、Androi
IO 是 Java 面试中一个非常重要的点。你应该很好掌握 Java IO,NIO,NIO2 以及与操作系统,磁盘 IO 相关的基础知识。下面是 Java IO 中经常问的问题。
在修改单元测试的过程中,不幸踩了个坑,发现 Powermockito 的PowerMock.mockStatic(ClassThatContainsStaticMethod.class) 在多线程场景下是无法正常工作的,这再次验证了之前 ThrougthWorks 顾问说的那句话:
实际上开发阶段两个核心的工作,开发和流程自测,自测的根本目的是为自己提前解决可能出现的问题;如果缺少自测和提测两个关键步骤,那么问题就会被传递给更多的用户,产生更多的资源消耗;
thenReturn 用来指定特定函数和参数调用的返回值。thenReturn 中可以指定多个返回值,在调用时返回值依次出现。若调用次数超过返回值的数量,再次调用时返回最后一个返回值。
单元测试是指对软件中的最小可测试单元进行检查和验证。单元在质量保证中是非常重要的环节,根据测试金字塔原理,越往上层的测试,所需的测试投入比例越大,效果也越差,而单元测试的成本要小的多,也更容易发现问题。
在异步系统的测试中,经常会涉及到了回调callback的单元测试。百度了一下异步测试之后,基本上的案例都来自于这里:
静态类的使用是一个有争议的话题,有人甚至提倡不要在类的名称上使用作用域限定符。关于静态特性争论的焦点在于一个被称为IoC控制反转的设计原则。
最近有个开发同学过来求助说某个系统接受的时候,发现里面的代码几乎没有单元测试,只是对几个DTO做了set/get的测试!看能不能帮忙指导下怎么开展。代码pull下来看了看,写了个demo,顺便解决了两个Mock方面的问题,提交上去供开发同学继续写用例。
在Stack Overflow上找到了同样的错误,该报错是在使用了PowerMock框架后发生的,奇怪的是,某些同样使用该框架的测试类却不会报错,暂时不明白抛出该异常的根本原因,先记录下解决方法。
静态类与非静态类基本相同,但存在一个区别:静态类不能实例化。 也就是说,不能使用 new 关键字创建静态类类型的变量。 因为没有实例变量,所以要使用类名本身访问静态类的成员。 例如,如果名为 UtilityClass 的静态类有一个名为 MethodA 的公共方法,则按下面的示例所示调用该方法:
多继承在某些时候还是很有用的,所以python将多继承定义为mixin功能,字面理解为混入。
我们习惯把编程语言分类为机器语言(汇编语言)和高级语言(Fortran/Lisp/Cobol/Basic/C/Pascal /C++/Java/Perl/Python),选择使用高级语言编程而不是机器语言相信大家都能说出一两个理由(比汇编语言更容易和更清晰的表达性、多平台的可移植性,但需要一个专用的编译器或者是解释器)。
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/huyuyang6688/article/details/26224679
黑格尔有句名言:存在即合理。以此为论据的话,静态类的存在自然有其合理性。不过物极必反,一旦代码过于依赖静态类,其劣化的结局则不可避免。这就好比罂粟作为一种草本植物,有其在药理上的价值,但如果肆无忌惮的大量使用,它就变成了毒品。
领取专属 10元无门槛券
手把手带您无忧上云