在过去一年左右的时间里，我一直在开发我的 TDD 印章，所以我现在相当擅长基本要素——首先编写测试，模拟框架，尽可能地测试小东西，DI 等。
但是我觉得仍然有很多事情我没有摆脱单元测试。
例如，我经常发现以这种方式进行的单元测试并没有真正测试我的代码应该做什么的集成和整体大局。当一切都被 mock 后，我发现我忽略了被测试的方法是否产生了我真正需要的结果，而不仅仅是他们所说的将提供的结果。当我开始转向 BDD 时，我发现这个问题只会加剧，导致开发时间浪费和测试无效。
另一个问题是单元测试需要大量的维护以保持它们的有序性，从而减慢了重构速度。
当我第一次开始单元测试时，和大多数人一样，我发现我写的东西实际上是集成测试。然而，这些测试有很多好处——它们更容易阅读，并且可以作为我的程序 API 的体面文档。他们还倾向于更快地捕捉现实世界的问题，而不是单元测试，我发现单元测试花费了大量时间来定位只有通过不正确使用 API 才会出现的边缘情况(例如空引用、除以 0 等)。
你有什么想法？你能推荐一些好书、文章或实践来解决更高级的单元测试并保持生产力和有效性吗？
编辑:给出答案，只需稍微跟随问题:所以基本上你是说尽管做了所有这些单元“测试”，但我并不是真的在测试代码......我回答说，“但我想测试该死的代码!
事实上，当我编写大量“更重”的集成测试时，我发现我的代码往往会更快地达到正确状态，并且更早地发现错误。是否有可能在没有集成测试的可维护性问题的情况下实现这一点？
最佳答案
TDD 和 BDD 并不是用来衡量代码质量的工具，而是用来帮助设计松散耦合、高度可维护的代码片段的工具。它与 API 设计的关系比其他任何事情都多。它的目的是确保代码按照它所说的做，并且以一种更改代码的一部分不会影响其他部分的方式来执行。
我希望您对 BDD 感到恼火是因为期望您编写工具只是为了“消除错误”或“替换您的 QA 流程”，而这两者都不是 BDD 和 TDD 的本意。测试驱动开发意味着“开发，由测试驱动”，而不是“测试，由开发驱动”。在我看来，你想要后者。
集成测试和软件质量保证是完全不同的主题，但我理解这些之间的大量混淆以及将 TDD 与它们联系起来的原因。
测试驱动开发意味着“开发，由测试驱动”，而不是“测试，由开发驱动”。在我看来，你想要后者。
更新 只想分享我关于这个问题的博客条目:Repeat after me: Test Driven Development is about design, NOT testing!
关于unit-testing - 将单元测试提升到一个新的水平，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1010819/