二． 测试的粒度，我们到底应该把粒度控制到多细？

对于数据不稳定的讨论：http://www.iteye.com/topic/221103

是不是一定要测试到具体数值才叫具体？在没有找到新方法之前，想保证测试具体到结果或者说是数值准确，那这个测试代码会表现的非常脆弱，而花费了很多心思去写出完美的测试最后这段测试代码也没有测出任何问题，有些得不偿失了。
为什么要写测试？
都是为了写出健壮的代码，正确的行为，获得重构的勇气等等。
好，如果说写出健壮代码需要写很细粒度的TestCase，而且数据库通常不支持我们这样做。导致测试很难写。

我想说，测试是分很多类型的，也可以认为是关注着不同的方向。
比如TestCase就要保证我的测试比较完善，包括对结果的验证，边界条件检查等等，这样的测试包括了我们业务代码的方方面面，包括在开发时想到的，没想到的。通过细粒度来提高我们程序的健壮性。也可以说是逼我们写出健壮的代码。
在比如TDD，其实TDD所关注的是需求，也就是代码的行为。他要保证业务代码被实现后确实做了我们预想的事情。很多时候我们不太关心TestCase的边界条件，毕竟，客户要件棉袄，这件棉袄可以过冬就行了，而我们花了很多时间做出了一个刀枪不入，甚至能穿着去外太空的棉袄，用户可能永远都不能用上这些花哨的功能。TDD需要小步快跑。不需要笨重的测试代码。
    上面两个简单例子他们都能为我们提供重构的勇气。同时可以发现不同的测试方法对于测试的关注点是不一样的。
我们的测试应该更多的关注行为。而不是去扣活的数据。数据的准确性是应该在我们开发代码时，最晚也是发布之前一定要确保的。那么我们现在关注的就只有行为，行为是否正确，行为是否被执行。这样对于测试，我们完全可以写出覆盖度非常高而且对数据依赖非常小的测试代码。比如
Void TestGetSomeReport(){
List list = someDao.getSomeReport();
assertNotNull(list);
}
这样就行了，这样的测试关注的是我的Dao是否被执行，如果执行表结构是否支持（如果表结构更变会得到通知）。而且对数据的依赖非常小。我们根本不需要去验证他们。现阶段我们只要保证所有的流程都会在测试中执行，这样就可以了。
如果进行重构这些反映代码行为的测试会告知重构者，他们是做什么的，当时的那个程序员的思考过程。这已经足够了，如果你不能保证重构之后的结果依然正确，就暂时不要去触碰他，等你有足够能力去保证产出的代码可以有正确结果之后在考虑这些。


由于我们暂时还不能得到稳定的测试数据，所以准备采用测试行为的方式。而更少去关注细节。对于业务型代码，粒度会加细。
由于推广测试的路途坎坷，不能一下子全部搞好，所以，准备先以粗粒度进行，并且保证覆盖度。

评论

16 楼 yh_private 2008-08-15  

amonlei 写道

单元测试： 看代码覆盖率
集成测试：看业务操作覆盖率

不能一概而论，这两点我们处理的很理想，有兴趣可以讨论讨论

好.我现在的问题就是鼓励大家去写测试但似乎没有什么效果.因为是老项目.以前都没有什么测试代码的.大家也都习惯了没有测试的日子.
表现就是代码覆盖率是根本不动.
又不好逼着他们做测试.闲的时候都是去上网聊天.没见人主动做测试,而且给我找出N多理由.

15 楼 amonlei 2008-08-14  

单元测试： 看代码覆盖率
集成测试：看业务操作覆盖率

不能一概而论，这两点我们处理的很理想，有兴趣可以讨论讨论

14 楼 gigix 2008-08-05  

daquan198163 写道

另外每次都让hibernate重建表，每个测试后spring自动回滚事务
没觉得太麻烦，这样其实最稳定、最省事，一劳永逸

而且这个速度很快，一个test case以后就是一条rollback

13 楼 daquan198163 2008-08-05  

抛出异常的爱 写道

勇气之类的是个虚词。。。。。
代码评审要时时刻刻作。。。。
每个svn记录后都要有人查看一次。。。
不然重构有什么意义？

敏捷的四个核心理念之一——勇气，怎么变成虚词了啊？呵呵
靠肉眼评审，能保证重构成功了吗？（没有改变系统的接口和行为）

12 楼 daquan198163 2008-08-05  

我就是像你说的方法一那样做的，在setUp里new 出很多VO准备数据
另外每次都让hibernate重建表，每个测试后spring自动回滚事务
没觉得太麻烦，这样其实最稳定、最省事，一劳永逸

麻不麻烦，其实很大程度上取决于是否了解他的全部好处，
我坚信，一个程序员如果真的了解TDD到回报，是肯定愿意去麻烦一下的

11 楼 yh_private 2008-08-04  

抛出异常的爱 写道

勇气之类的是个虚词。。。。。
代码评审要时时刻刻作。。。。
每个svn记录后都要有人查看一次。。。
不然重构有什么意义？

是不是虚词这个事情我不想讨论。至少我不喜欢去碰那些没有测试的代码。
代码评审我们是有的。我发这个帖子的意思是想问问大家在一个已经进行了几年的项目中，如何推广测试，如何让他们接受测试。而上面正是我现在存在的问题。数据不稳定如何进行测试？测试由浅入深。并且想请教下大家是如何在团队中推广测试的。而且我现在面临比较大的困难是，同志们通常很不习惯写测试。

10 楼 抛出异常的爱 2008-08-04  

yh_private 写道

gurudk 写道

yh_private 写道

抛出异常的爱 写道

主要看需求的写法
如果这回写错了，
下回写细一点。

必竟TDD是以不断变化为前题的。

哎~我们团队测试还在推广阶段，我是不想一次给他们灌输太多东西。而且要做的事情也很多。只能从浅入深，一点一点来。所以尽量降低测试的门槛。不让他们测试那么多事情。现在团队测试积极性不是很高，这个事情又不是靠逼就能逼出来的。

换个思路，代码评审对编码质量的提高更好。

代码评审如何给我们重构时带来勇气呢？难道每次重构就要把所有相关的代码全部审一遍，更何况表结构这样的变更需要非常细心的评审，实施起来恐怕比较难？

勇气之类的是个虚词。。。。。
代码评审要时时刻刻作。。。。
每个svn记录后都要有人查看一次。。。
不然重构有什么意义？

9 楼 yh_private 2008-08-02  

leton2008 写道

单元测试更关注开发者完成的单一主体功能的测试。
部分集成测试则关注功能完整性和正确性的一种测试。

难道单元测试不需要关注单一功能的正确性和完整性？单元测试的正确性是什么评定的？是否是某方法返回的结果呢？

比如这样一个方法。他查询数据库，并统计当前注册人数。而这个人数是不断变化的。我们的测试应该如何写呢？

8 楼 yh_private 2008-08-02  

gurudk 写道

yh_private 写道

抛出异常的爱 写道

主要看需求的写法
如果这回写错了，
下回写细一点。

必竟TDD是以不断变化为前题的。

哎~我们团队测试还在推广阶段，我是不想一次给他们灌输太多东西。而且要做的事情也很多。只能从浅入深，一点一点来。所以尽量降低测试的门槛。不让他们测试那么多事情。现在团队测试积极性不是很高，这个事情又不是靠逼就能逼出来的。

换个思路，代码评审对编码质量的提高更好。

代码评审如何给我们重构时带来勇气呢？难道每次重构就要把所有相关的代码全部审一遍，更何况表结构这样的变更需要非常细心的评审，实施起来恐怕比较难？

7 楼 gurudk 2008-08-02  

yh_private 写道

抛出异常的爱 写道

主要看需求的写法
如果这回写错了，
下回写细一点。

必竟TDD是以不断变化为前题的。

哎~我们团队测试还在推广阶段，我是不想一次给他们灌输太多东西。而且要做的事情也很多。只能从浅入深，一点一点来。所以尽量降低测试的门槛。不让他们测试那么多事情。现在团队测试积极性不是很高，这个事情又不是靠逼就能逼出来的。

换个思路，代码评审对编码质量的提高更好。

6 楼 leton2008 2008-07-31  

spiritfrog 写道

粒度主要是看关注点了，一般来说主要关注的是功能。
不知道tdd是用什么粒度的测试， 看lz的意思，既然不需要过于笨重的测试，那么还是以细粒度为主，步步为营了？这样确实有利于重构，是否又更加符合tdd的理念一点。

测试的粒度？
我不知道楼主想表达的意思是指在开发部门一侧的呢？还是测试部一侧的？

单元测试，功能性测试(部分集成测试),系统集成测试。
这3个层级的测试的粒度很明显是不一样的。

单元测试更关注开发者完成的单一主体功能的测试。
部分集成测试则关注功能完整性和正确性的一种测试。
以上两种我认为均可在研发部门进行和完成。

5 楼 photon 2008-07-30  

还用逼吗？重赏之下必有勇夫，给那些开发的速度快，质量高的程序员多发奖金就好了。

4 楼 yh_private 2008-07-30  

抛出异常的爱 写道

主要看需求的写法
如果这回写错了，
下回写细一点。

必竟TDD是以不断变化为前题的。

哎~我们团队测试还在推广阶段，我是不想一次给他们灌输太多东西。而且要做的事情也很多。只能从浅入深，一点一点来。所以尽量降低测试的门槛。不让他们测试那么多事情。现在团队测试积极性不是很高，这个事情又不是靠逼就能逼出来的。

3 楼 yh_private 2008-07-30  

spiritfrog 写道

粒度主要是看关注点了，一般来说主要关注的是功能。
不知道tdd是用什么粒度的测试， 看lz的意思，既然不需要过于笨重的测试，那么还是以细粒度为主，步步为营了？这样确实有利于重构，是否又更加符合tdd的理念一点。

的确，TestCase是要关注功能，但我们的数据总是变，不能把功能关注到结果的级别。所以我选择了关注行为，首先我的测试程序要保证在测试的时候所有行为都被执行。100%覆盖。这样可以保证发布出去的程序不会出现低级错误，比如一个表结构更变，在没有测试的时候我们要手工去找所有与这个表有关系的SQL，然后去修改，这样很容易出现遗漏。出现低级错误。
至于TDD，我想他与TestCase是不同的两个事情。

我没太明白你所说的    

引用

是否又更加符合tdd的理念一点。

2 楼 抛出异常的爱 2008-07-30  

主要看需求的写法
如果这回写错了，
下回写细一点。

必竟TDD是以不断变化为前题的。

1 楼 spiritfrog 2008-07-30  

粒度主要是看关注点了，一般来说主要关注的是功能。
不知道tdd是用什么粒度的测试， 看lz的意思，既然不需要过于笨重的测试，那么还是以细粒度为主，步步为营了？这样确实有利于重构，是否又更加符合tdd的理念一点。