tdd的粒度

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

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

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

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

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

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

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

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

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

unitTest + mock

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

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