单元测试 – 将单元测试提升到一个新的水平

在过去一年左右的时间里,我一直在开发我的TDD杂技,所以我现在相当擅长的要素 – 首先编写测试,嘲笑框架,尽可能小的测试,DI等.

不过,我觉得还有很多事情我没有得到单元测试.

例如,我经常发现,以这种方式进行单元测试并不能真正测试我的代码应该在做什么的集成和整体更大的图景.随着嘲笑的一切,我发现我不知道所测试的方法是否产生了我实际需要的结果,而不仅仅是他们所提供的结果.当我开始转向BDD时,我发现这个问题只会加剧,导致开发时间浪费和无效测试.

另一个问题是单元测试需要大量的维护来保持它们的顺序,减缓重构.

当我第一次开始单元测试时,像大多数人一样,我发现我正在写的是真正的集成测试.然而,这些测试有很多好处 – 它们更容易阅读,并且作为我的程序API的体面文档.他们也倾向于更快地捕捉现实世界的问题,而不是单位测试,我发现花费在很多时间上,针对仅通过不正确使用API​​(例如空引用,除以0等)引发的边缘案例.

你怎么看？你能推荐一些好的书籍,文章或实践来处理更先进的单元测试,并保持生产力和效率？

编辑：只是一点点问题,给出答案：所以基本上你说,尽管做所有这个单位’测试’我不是真的正在测试的代码…我回复,’但我想测试ang码！
事实上,当我写了很多“较重的”集成测试时,我发现我的代码往往更快地达到了正确的状态,并且错误早已被识别.没有集成测试的可维护性问题可以实现这一点吗？

TDD和BDD不是要测量代码质量的工具,它们是用来帮助设计松散耦合,高度可维护的代码段的工具.它比其他任何事情都有更多的API设计.这意味着确保代码执行它所说的操作,并且以改变代码的一部分不会影响其他部分的方式.

我会期望您对BDD感到愤怒的感觉是由于您期望您正在编写工具来简单地“消除错误”或“替换您的质量保证过程”,这两者都不是BDD或TDD都不会做的.测试驱动的发展意味着“由测试驱动的发展”,而不是“由开发驱动的测试”.在我看来,你想要后者.

集成测试和软件质量保证是完全不同的主题,但我明白了这些与这些TDD相关联的巨大混乱背后的原因.

测试驱动的发展意味着“由测试驱动的发展”,你想要后者.

更新只是想分享我的博客条目关于这个问题：Repeat after me: Test Driven Development is about design,NOT testing!