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

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

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

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


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