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

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

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

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

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

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