tdd的粒度

   发现这个问题目前还处于空白状态，搜了很久没看见讨论。希望管理员不要把它移到问答区，大家发帖子或多或少都会有些疑问，没疑问的帖子还会有讨论价值吗。
   进入正题。一个系统的功能结构都是树形的，底层的最简单，越往上就越复杂，因为它对底层功能的集成越来越多。刚开始时的测试都是针对底层编写的，这很轻松，基本上没问题；可当需要编写高层功能时，问题就来了：要不要写测试？
1、写。这就是每一层都写测试，层级越多就意味着底层的代码重复测试的次数也越多，tdd强调频繁运行测试，这不是很浪费时间?这还不够严重,假如该层集成的某些功能不是自己写的，无法保证其可靠性，这又该如何?其实问题可以总结为：我希望“A依赖于B，但A的测试只会因为A的问题而出现问题，跟B无干”。结论是，层级越高的功能，测试越难编写，越受限制。
2、不写。只针对所有的底层代码编写testCase。那高层的代码怎么办，连testCase都没有可靠性从何谈起？
   从个人的实践来看，这个问题很实际。

评论

13 楼 抛出异常的爱 2011-06-02  

yizhilong28 写道

测试代码的维护确实是件很头疼的问题，特别是团队有人是TDD,有人根本就没单元测试。

没有测试 的代码删了它..........
这点成本魄力没有别谈团队管理

12 楼 yuan 2011-06-01  

yizhilong28 写道

测试代码的维护确实是件很头疼的问题，特别是团队有人是TDD,有人根本就没单元测试。

在一个并不是每个人都写测试的团队里，可以每次checkout代码的时候马上先跑一下测试。如果测试不通过，查log找引起问题的人讨论，如果是需求变更，就修改相应的测试（描述这个新的需求）；如果是个bug就改bug。

11 楼 yizhilong28 2011-06-01  

测试代码的维护确实是件很头疼的问题，特别是团队有人是TDD,有人根本就没单元测试。

10 楼 seemoon 2011-05-31  

从测试价值最大的地方开始，团队能力越高，测试范围越大。但是现在国内很多团队只是t，没有d(riven)，要靠个人摸索，不到上万行测试代码，都是扯谈。

9 楼 niva 2011-05-31  

用大师的话说，就是“高层不依赖于底层，他们共同依赖于抽象”，说白了就是把底层多实现个接口，然后去Mock，这样你就可以独立于底层，来进行测试了。

不过就我的实际体验来讲，大部分时候高层确实没有什么好测的，多数是对底层的组织、委派，Mock起来也是非常的麻烦，测试代码要写一大堆，Mock工具有时候也很不爽，很难按照自己的意愿来Mock，更杯具的是，一旦需求发生意料之外的变化，许多测试代码都要重新写，所以我现在实在不愿意为高层写测试代码，宁可做些手工测试，出了问题debug一下，可能是我功力不够深吧。

8 楼 bastengao 2011-05-25  

unitTest + mock

7 楼 piao_bo_yi 2011-05-25  

LZ希望“A依赖B，但A的测试只会因为A的问题而出现问题，跟B无干”实际上，很难完全做到。可以用MOCK解决部分问题。但如果你正在使用带副作用的编程语言（如JAVA)，则很难做到完全的隔离。完全的隔离意味着很多细小的函数（仅仅是为了测试而做的重构）。最容易隔离的情形是业务逻辑和从周围取数据的隔离。但对于A和B都是业务逻辑层的情形，一般是隐含了B正确的假设。所以测试一般能测出来问题，但是是哪个模块出问题，可能还是得亲自调试一下。具体的平衡得自己把握。

6 楼 BruceXX 2011-05-19  

使用mock来对高层做单元测试，最初的时候底层的东西我们是用单元测试来模拟，高层用集成测试来模拟，但是集成测试的配置环境很容易变动，所以后期我们直接用mock来做高层的test

5 楼 skypengyc 2011-05-18  

现在都用TDD的开发方法在开发项目吗？

4 楼 hyj1254 2011-05-14  

yuan 写道

可以试着把每层隔离开来，让高层不依赖底层，单独测试，mock、stub就是用来干这个的。

谢谢，这么做确实可以达到效果。

3 楼 yuan 2011-05-12  

假如集成进来的某个库不是你自己写的，那么只要测试那个被集成进来的库的接口是否被正确调用了即可，不必再深入到那个库里面去连库一起测。

当然，那个库最好是自己有一套完全的测试代码，否则它不可靠。

2 楼 yuan 2011-05-12  

可以试着把每层隔离开来，让高层不依赖底层，单独测试，mock、stub就是用来干这个的。

1 楼 抛出异常的爱 2011-05-11  

hyj1254 写道

   发现这个问题目前还处于空白状态，搜了很久没看见讨论。希望管理员不要把它移到问答区，大家发帖子或多或少都会有些疑问，没疑问的帖子还会有讨论价值吗。
   进入正题。一个系统的功能结构都是树形的，底层的最简单，越往上就越复杂，因为它对底层功能的集成越来越多。刚开始时的测试都是针对底层编写的，这很轻松，基本上没问题；可当需要编写高层功能时，问题就来了：要不要写测试？
1、写。这就是每一层都写测试，层级越多就意味着底层的代码重复测试的次数也越多，tdd强调频繁运行测试，这不是很浪费时间?这还不够严重,假如该层集成的某些功能不是自己写的，无法保证其可靠性比如其依赖的模块也是未知的，这又该如何?结论是，层级越高的功能，测试越难编写，越受限制。
2、不写。只针对所有的底层代码编写testCase。那高层的代码怎么办，连testCase都没有可靠性从何谈起？
   从个人的实践来看，这个问题很实际。

1.KISS
2.越复杂越容易出错,越容易出错需要测试,
3.重构成简单易懂东西,把关系变成简单关系