利用Continuous Testing实现Eclipse环境自己主动单元測试

当你Eclipse环境中改动项目中的某个方法时,你可能因为各种原因没有执行单元測试,结果代码提交,悲剧就可能随之而来。

所幸infinitest(http://infinitest.github.io/)提供了一个Continuous
Testing插件,以及时自己主动执行单元測试。尽管会多占一些CPU资源,但开发者的硬件谁会不留一点余地呢?大不了,音乐、视频、360卸载就OK了。安装方法有两种:

(1)使用"Install new
software",输入地址:http://infinitest.github.io/

(2)使用MarketPlace,速度确实快,谁用谁知道

安装好之后,重新启动Eclipse,Continuous Testing默认自己主动启动。

我们新建一个项目AutoTesting,打印一个简单的乘法口诀:

再建一个单元測试项目AutoUnitTesting:

改动一下原方法,添加一行“int
num2 = 1 / 0;”,当保存改动时,Continuous
Testing已经自己主动执行并在左下角显示结果。

当修正方法后,Continuous Testing会再次自己主动执行:

OK,这个功能是不是非常cool,至少会为我们节省一点点时间,歇息片刻,或跟MM聊两句,不是吗?

差点忘了,假设不想启用Continuous Testing,在Performance-general-InfiniteTest-去掉勾就可以。

邀月注:本文版权由邀月和CSDN共同全部,转载请注明出处。

助人等于自助!   [email protected]

利用Continuous Testing实现Eclipse环境自己主动单元測试,布布扣,bubuko.com

时间: 2024-10-12 22:41:28

利用Continuous Testing实现Eclipse环境自己主动单元測试的相关文章

利用Continuous Testing实现Eclipse环境自动单元测试

当你Eclipse环境中修改项目中的某个方法时,你可能由于各种原因没有运行单元测试,结果代码提交,悲剧就可能随之而来. 所幸infinitest(http://infinitest.github.io/)提供了一个Continuous Testing插件,以及时自动运行单元测试.虽然会多占一些CPU资源,但开发人员的硬件谁会不留一点余地呢?大不了,音乐.视频.360卸载就OK了.安装方法有两种: (1)使用"Install new software",输入地址:http://infin

MAC中在eclipse luna上搭建移动平台自己主动化測试框架(UIAutomator/Appium/Robotium/MonkeyRunner)关键点记录

这几天由于原来在用的hp laptop的电池坏掉了,机器一不小心就断电.所以仅仅能花时间在自己的mackbook pro上又一次搭建整套环境.大家都知道搭建好开发环境是个非常琐碎须要耐心的事情,特别是当你搭建的安卓平台的时候常常须要FQ,那个慢不是常人能够忍受的.所以过程中建议大家边看书或者玩手机边搭建,省得一直瞪着屏幕导致爆血管的意外发生. 这里本人尝试把在mac上搭建移动平台自己主动化測试框架的一些碰到的问题和关键点给描写叙述一下.以方便后来者能够借鉴. 1. 假设你须要的是最新的eclis

Android自己主动化測试之Monkeyrunner用法及实例

眼下android SDK里自带的现成的測试工具有monkey 和 monkeyrunner两个.大家别看这俩兄弟名字相像,但事实上是完全然全不同的两个工具,应用在不同的測试领域.总的来说,monkey主要应用在压力和可靠性測试上,执行该命令能够随机地向目标程序发送各种模拟键盘事件流,而且能够自定义发送的次数,以此观察被測应用程序的稳定性和可靠性,应用起来也比較简单,记住那几个命令即可了.而monkeyrunner呢,相比之下会强大一些,它主要可应用于功能測试,回归測试,而且能够自定义測试扩展,

Mock+Proxy在SDK项目的自己主动化測试实战

项目背景 广告SDK项目是为应用程序APP开发者提供移动广告平台接入的API程序集合,其形态就是一个植入宿主APP的jar包.提供的功能主要有以下几点: - 为APP请求广告内容 - 用户行为打点 - 错误日志打点 - 反作弊 团队现状 在项目推进的过程中.逐渐暴露了一些问题: 1. 项目团队分为上海团队(服务端)和北京团队(client),因为信息同步,人力资源等其它原因.服务端与client的开发进度非常难保持同步,经常出现client等着和服务端联调的情况 2. 接口文档不稳定,理解有偏差

Android自己主动化測试解决方式

如今,已经有大量的Android自己主动化測试架构或工具可供我们使用,当中包含:Activity Instrumentation, MonkeyRunner, Robotium, 以及Robolectric.另外LessPainful也提供服务来进行真实设备上的自己主动化測试. Android自身提供了对instrumentation測试的基本支持,当中之中的一个就是位于android.test包内的ActivityInstrumentationTestCase2类,它扩展了JUnit的Test

在Eclipse中使用JUnit4进行单元測试(0基础篇)

本文绝大部分内容引自这篇文章: http://www.devx.com/Java/Article/31983/0/page/1 我们在编写大型程序的时候,须要写成千上万个方法或函数,这些函数的功能可能非常强大,但我们在程序中仅仅用到该函数的一小部分功能,而且经过调试能够确定,这一小部分功能是正确的.可是,我们同一时候应该确保每个函数都全然正确,由于假设我们今后假设对程序进行扩展,用到了某个函数的其它功能,而这个功能有bug的话,那绝对是一件非常郁闷的事情.所以说,每编写完一个函数之后,都应该对这

带有机器人框架的.NET自己主动化測试

Clayton Neal在软件測试和质量保证方面有超过13年的经验,当中有八年的Windows, web,和移动应用程序的測试自己主动化经验.他在測试领域的全部等级都工作过.近期他在Bloomberg and Misys担任QA经理.同一时候他还是Sogeti的自己主动化測试顾问.Clayton对自己主动化測试超迷恋,还见识了怎样亲自成功实施測试自己主动化. ? 測试自己主动化的优点我们都非常清楚,更快地反馈问题,降低手工測试,持续集成就是当中随口可举的.測试团队成员越多,公司使用自己主动化越多

Selenium2 Python 自己主动化測试实战学习笔记(五)

7.1 自己主动化測试用例 无论是功能測试.性能測试和自己主动化測试时都须要编写測试用例,測试用例的好坏能准确的体现了測试人员的经验.能力以及对项目的深度理解. 7.1.1 手工測试用例与自己主动化測试用例 手工測试用例是针对手工測试人员.自己主动化測试用例是针对自己主动化測试框架.前者是手工測试用例人员应用手工方式进行用例解析,后者是应用脚本技术进行用例解析. 前者具有较好的异常处理能力,并且可以基于測试用例,制造各种不同的逻辑推断,并且人工測试步步跟踪,可以仔细定位问题.后者全然依照測试用例

Robot Framework自己主动化測试框架之我见

一些自己主动化測试现状: 盲目的去做自己主动化,终于以失败告终. 觉得是能提高效率的事情.却推广不下去: 事实上上述问题产生的原因是: 自己主动化測试案例稳定性不高,可维护性比較差: 自己主动化測试工具学习成本高,自己主动化測试人员的成本高: 而RF(Robot Framework,后面都简称RF)具备良好的分层思想.它将測试人员分为懂开发和不懂开发的,懂开发来负责底层keyword开发和维护,供不懂开发的測试人员调用,通过填写表格的形式用自言语言来写自己主动化測试用例.这样写出来的用例測试用例