浏览 13093 次
|
锁定老帖子 主题：再开Junit的话题
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2003-09-18
robbin,我转一个我自己的问题来.占个地盘.
虽说我自己已经有些具体的想法了,不过还是在查看资料当中,很想听听把Junit用到较大项目上面的人的具体经验型的看法. 现在我比较同意的一个观点是,用Xunit来测试的话,不需要对全部的代码测试,只要测试那些关键的,容易出错的部分就好了.(来自Dlee的看法) 发表于: 星期一 九月 15, 2003 8:50 pm 发表主题: 请教各位使用JUnit的同学问题. -------------------------------------------------------------------------------- 本来想问问CPPUnit的问题的,想来再坐的各位玩Java的多点,就问Junit的好了. 毕竟原理上差不多的. 我主要有以下几个问题. 1. 单元测试的时候,关于错误处理部分代码的测试. 一个函数中,为了保证不出错,那么不可避免的很多错误处理的代码.这个部分的代码的测试,从单元测试的角度来看应该都要测试过才对. 这个时候的测试应该是叫错误测试吧. 这个测试的最终结果是为了函数出错. 那么如果成功出错,那么单元测试应该是测试OK,是不是? 我翻了翻前面的joe贴的Junit的学习帖子.里面的意思是 Fail和Error是两个概念,一个是测试不通过,一个是错误测试故意出错. 这个在我的写的代码中,正常的流程测试比较容易,但是很多错误都是在错误处理上面的.为了测试错误处理部分.就要给出很多的测试初始值来作测试. 于是有了2. 2. 一个函数完整的单元测试是否应该包括函数的全部的流程. 这个如果,一个函数的流程比较复杂的话,好像要给很多初始条件和很多次测试才能比较完整的. 再这里总有那免会遗漏的感觉. 同学们是如何处理这个问题的? 3.过分依赖于外部条件的函数如何测试. 比如我现在写一个SMTP类,那么很多数据是从SMTP 服务器来的, 在这种情况之下,怎么给出测试过程中需要的数据? 还有比如某个函数里面临时需要很多数据库的数据. 又该如何如何给定测试初始值,这些函数运行过程中得到的数据,又该怎么给? 因为,我看到的资料里面好像是这样写的"如果被测试对象依赖于某个对象或者函数,那么就要给一个空的对象或者空的函数来作测试,以隔离相关性的影响." 话虽然这么说,但是如果某些值不给的话,函数本身的运行就有些困难了,那么函数的测试也就不真实了.这里又该怎么处理? 声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
|
发表时间：2003-09-18
这是我一直在考虑的问题，自动测试和重构的问题我们在今年以内是一定要解决的。到时候我会写一些经验出来。
对于测试，实用主义的观点是最正确的，一定要注重实效，如果用户测试可以生效，暂时就没有必要进行自动测试。要在成本、收益和开发效率上取得平衡。 做好测试，归根到底还是一个管理问题。每个人的责任心是不同的。因此，一个 Bug-tracking System 配合必要的考核制度是必要的。 我记得有一本书叫做《面向对象的软件测试》，可以用来做为指导。xUnit 毕竟只是一个工具。 http://www.cnforyou.com/query/bookdetail.asp?viBookCode=6217 |
| 返回顶楼 | |
|
发表时间：2003-09-19
测试这个东西，非常的费时间，尤其是测试数据的准备，是这次测试效果能否达到的关键。
因此，我一般从一开始就要注意到关键的东西：数据。把数据分门别类，然后再总结，剔除那些根本不可能发生的数据，我觉得工作量会降低很多。 而且，单元测试并不需要测试每一个方法，简单、一目了然的那些方法可以拿下，哪些关系到业务逻辑的方法不能放过。 |
| 返回顶楼 | |
|
发表时间：2003-09-19
公司的团队在测试这个环节上一点都不重视，写得代码很少测试就拿来跑，结果就可想而知了。对测试的歧视啊。。。。
|
| 返回顶楼 | |
|
发表时间：2003-09-19
后山 写道 测试这个东西，非常的费时间，尤其是测试数据的准备，是这次测试效果能否达到的关键。
因此，我一般从一开始就要注意到关键的东西：数据。把数据分门别类，然后再总结，剔除那些根本不可能发生的数据，我觉得工作量会降低很多。 而且，单元测试并不需要测试每一个方法，简单、一目了然的那些方法可以拿下，哪些关系到业务逻辑的方法不能放过。 谢谢, 我的想法是这样的.单元测试是对于大部分正常的流程的,而且我觉的单元测试的主要目的是减少代码修改中出现的各种人为的错误问题. |
| 返回顶楼 | |
|
发表时间：2003-09-19
测试主要看程序的逻辑，并不是每个类或者方法都要测试的，那样你累死了也没有人看的。写测试的时候能看出设计的好坏，模块的可测试性
|
| 返回顶楼 | |
|
发表时间：2004-05-10
blureyes 写道 写test case是件麻烦事，有时候为了写test case，不得不创建大量的环境，并且修改原先的接口定义，写test case的时间往往会占到写code的1/3时间。
。。。。。。。。 我们可以在client实现一个DataSource接口，做test case时作为参数给accessDatabase，在实际的app server运行的时候，用app server里定义的data source。 为什么要在写测试用例的时候修改原先的接口呢？单元测试（没记错的话）来自XP.而在XP中Test First是首要的。 建议看看Test Driven Design |
| 返回顶楼 | |
|
发表时间：2004-05-10
单元测试测试的是一个你认为或者软件需求规格说明书中定义的一个很小的可以叫做单元的功能。不一定测试所有的public方法。但一般一个public方法实现的是一个功能。
单元测试主要是为了帮正你的接口对外一致，当你修改接口的时候一定要修改测试。按照XP的精神，应该实现修改测试。 测试一个功能要编写满足这个功能的测试，也要编写不满足这个功能的测试。 |
| 返回顶楼 | |
|
发表时间：2004-05-11
blureyes 写道 写test case是件麻烦事，有时候为了写test case，不得不创建大量的环境，并且修改原先的接口定义，写test case的时间往往会占到写code的1/3时间。
对于问题1.2，我的看法是把引起错误的相关代码和处理出错的代码分开，对处理出错的代码做test case，对正常流程做test case。 对于问题3，我们不得不考虑我们的接口设计，比如有个方法是要访问数据库，原先的定义可能为 void accessDatabase(){ DataSource ds = getDataSource(); Connection con = ds.getConnection(); } 这样的代码在运行test case的时候不得不要同时打开app server，否则就会因为lookup不到data source而报错。而且用jboss的话，client通过lookup也得不到data source。 所以我们要重构我么得代码，定义为 void accessDatabase(DataSource ds){ Connection con = ds.getConnection(); } 我们可以在client实现一个DataSource接口，做test case时作为参数给accessDatabase，在实际的app server运行的时候，用app server里定义的data source。 我想 模拟对象就是你要的. |
| 返回顶楼 | |
