精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2008-07-30
http://www.iteye.com/topic/221103
对于数据不稳定的讨论:是不是一定要测试到具体数值才叫具体?在没有找到新方法之前,想保证测试具体到结果或者说是数值准确,那这个测试代码会表现的非常脆弱,而花费了很多心思去写出完美的测试最后这段测试代码也没有测出任何问题,有些得不偿失了。 为什么要写测试? 都是为了写出健壮的代码,正确的行为,获得重构的勇气等等。 好,如果说写出健壮代码需要写很细粒度的TestCase,而且数据库通常不支持我们这样做。导致测试很难写。 我想说,测试是分很多类型的,也可以认为是关注着不同的方向。 比如TestCase就要保证我的测试比较完善,包括对结果的验证,边界条件检查等等,这样的测试包括了我们业务代码的方方面面,包括在开发时想到的,没想到的。通过细粒度来提高我们程序的健壮性。也可以说是逼我们写出健壮的代码。 在比如TDD,其实TDD所关注的是需求,也就是代码的行为。他要保证业务代码被实现后确实做了我们预想的事情。很多时候我们不太关心TestCase的边界条件,毕竟,客户要件棉袄,这件棉袄可以过冬就行了,而我们花了很多时间做出了一个刀枪不入,甚至能穿着去外太空的棉袄,用户可能永远都不能用上这些花哨的功能。TDD需要小步快跑。不需要笨重的测试代码。 上面两个简单例子他们都能为我们提供重构的勇气。同时可以发现不同的测试方法对于测试的关注点是不一样的。 我们的测试应该更多的关注行为。而不是去扣活的数据。数据的准确性是应该在我们开发代码时,最晚也是发布之前一定要确保的。那么我们现在关注的就只有行为,行为是否正确,行为是否被执行。这样对于测试,我们完全可以写出覆盖度非常高而且对数据依赖非常小的测试代码。比如 Void TestGetSomeReport(){ List list = someDao.getSomeReport(); assertNotNull(list); } 这样就行了,这样的测试关注的是我的Dao是否被执行,如果执行表结构是否支持(如果表结构更变会得到通知)。而且对数据的依赖非常小。我们根本不需要去验证他们。现阶段我们只要保证所有的流程都会在测试中执行,这样就可以了。 如果进行重构这些反映代码行为的测试会告知重构者,他们是做什么的,当时的那个程序员的思考过程。这已经足够了,如果你不能保证重构之后的结果依然正确,就暂时不要去触碰他,等你有足够能力去保证产出的代码可以有正确结果之后在考虑这些。 由于我们暂时还不能得到稳定的测试数据,所以准备采用测试行为的方式。而更少去关注细节。对于业务型代码,粒度会加细。 由于推广测试的路途坎坷,不能一下子全部搞好,所以,准备先以粗粒度进行,并且保证覆盖度。 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2008-07-30
粒度主要是看关注点了,一般来说主要关注的是功能。
不知道tdd是用什么粒度的测试, 看lz的意思,既然不需要过于笨重的测试,那么还是以细粒度为主,步步为营了?这样确实有利于重构,是否又更加符合tdd的理念一点。 |
|
返回顶楼 | |
发表时间:2008-07-30
主要看需求的写法
如果这回写错了, 下回写细一点。 必竟TDD是以不断变化为前题的。 |
|
返回顶楼 | |
发表时间:2008-07-30
spiritfrog 写道 粒度主要是看关注点了,一般来说主要关注的是功能。
不知道tdd是用什么粒度的测试, 看lz的意思,既然不需要过于笨重的测试,那么还是以细粒度为主,步步为营了?这样确实有利于重构,是否又更加符合tdd的理念一点。 的确,TestCase是要关注功能,但我们的数据总是变,不能把功能关注到结果的级别。所以我选择了关注行为,首先我的测试程序要保证在测试的时候所有行为都被执行。100%覆盖。这样可以保证发布出去的程序不会出现低级错误,比如一个表结构更变,在没有测试的时候我们要手工去找所有与这个表有关系的SQL,然后去修改,这样很容易出现遗漏。出现低级错误。 至于TDD,我想他与TestCase是不同的两个事情。 我没太明白你所说的 引用 是否又更加符合tdd的理念一点。
|
|
返回顶楼 | |
发表时间:2008-07-30
抛出异常的爱 写道 主要看需求的写法
如果这回写错了, 下回写细一点。 必竟TDD是以不断变化为前题的。 哎~我们团队测试还在推广阶段,我是不想一次给他们灌输太多东西。而且要做的事情也很多。只能从浅入深,一点一点来。所以尽量降低测试的门槛。不让他们测试那么多事情。现在团队测试积极性不是很高,这个事情又不是靠逼就能逼出来的。 |
|
返回顶楼 | |
发表时间:2008-07-30
还用逼吗?重赏之下必有勇夫,给那些开发的速度快,质量高的程序员多发奖金就好了。
|
|
返回顶楼 | |
发表时间:2008-07-31
spiritfrog 写道 粒度主要是看关注点了,一般来说主要关注的是功能。
不知道tdd是用什么粒度的测试, 看lz的意思,既然不需要过于笨重的测试,那么还是以细粒度为主,步步为营了?这样确实有利于重构,是否又更加符合tdd的理念一点。 测试的粒度? 我不知道楼主想表达的意思是指在开发部门一侧的呢?还是测试部一侧的? 单元测试,功能性测试(部分集成测试),系统集成测试。 这3个层级的测试的粒度很明显是不一样的。 单元测试更关注开发者完成的单一主体功能的测试。 部分集成测试则关注功能完整性和正确性的一种测试。 以上两种我认为均可在研发部门进行和完成。 |
|
返回顶楼 | |
发表时间:2008-08-02
yh_private 写道 抛出异常的爱 写道 主要看需求的写法
如果这回写错了, 下回写细一点。 必竟TDD是以不断变化为前题的。 哎~我们团队测试还在推广阶段,我是不想一次给他们灌输太多东西。而且要做的事情也很多。只能从浅入深,一点一点来。所以尽量降低测试的门槛。不让他们测试那么多事情。现在团队测试积极性不是很高,这个事情又不是靠逼就能逼出来的。 换个思路,代码评审对编码质量的提高更好。 |
|
返回顶楼 | |
发表时间:2008-08-02
gurudk 写道 yh_private 写道 抛出异常的爱 写道 主要看需求的写法
如果这回写错了, 下回写细一点。 必竟TDD是以不断变化为前题的。 哎~我们团队测试还在推广阶段,我是不想一次给他们灌输太多东西。而且要做的事情也很多。只能从浅入深,一点一点来。所以尽量降低测试的门槛。不让他们测试那么多事情。现在团队测试积极性不是很高,这个事情又不是靠逼就能逼出来的。 换个思路,代码评审对编码质量的提高更好。 代码评审如何给我们重构时带来勇气呢?难道每次重构就要把所有相关的代码全部审一遍,更何况表结构这样的变更需要非常细心的评审,实施起来恐怕比较难? |
|
返回顶楼 | |
发表时间:2008-08-02
leton2008 写道 单元测试更关注开发者完成的单一主体功能的测试。 部分集成测试则关注功能完整性和正确性的一种测试。 难道单元测试不需要关注单一功能的正确性和完整性?单元测试的正确性是什么评定的?是否是某方法返回的结果呢? 比如这样一个方法。他查询数据库,并统计当前注册人数。而这个人数是不断变化的。我们的测试应该如何写呢? |
|
返回顶楼 | |