在过去一年左右的时间里,我一直在开发我的TDD印章,以便我现在相当擅长基本要点 - 首先编写测试,模拟框架,测试尽可能小的东西,DI等.
但是我觉得还有很多事情我没有从单元测试中解脱出来.
例如,我经常发现这样并没有真正测试集成和整体单元测试大局观的什么我的代码是应该做的事情.随着一切被嘲笑,我发现我忽略了被测方法是否产生了我实际需要的结果,而不仅仅是他们所说的结果.当我开始转向BDD时,我发现这个问题只会加剧,导致浪费的开发时间和无效的测试.
另一个问题是单元测试需要大量维护才能使它们保持有序,从而减慢重构速度.
当我第一次开始单元测试时,像大多数人一样,我发现我写的内容实际上是集成测试.然而,这些测试有许多好处 - 它们更易于阅读,并且在我的程序API上充当了不错的文档.他们也倾向于更快地捕捉现实世界的问题,而不是单位测试,我发现他花了很多时间来定位只会因错误使用API而产生的边缘情况(例如空引用,除以0等).
你的想法是什么？您能否推荐能够解决更先进的单元测试并保持生产力和效率的优秀书籍,文章或实践？
编辑:只是一点点跟随问题,给出答案:所以基本上你说,尽管做了所有这个单位'测试'我真的没有测试代码......我回答,'但我想测试当代码!' 实际上,当我写了很多"较重"的集成测试时,我发现我的代码往往更快地达到正确状态,并且很早就发现了错误.如果没有集成测试的可维护性问题,是否有可能实现这一目标？
TDD和BDD并不意味着是衡量代码质量的工具,他们注定是工具设计松散耦合,代码高度维护件提供帮助.它有更多关于API设计的事情.它的目的是确保代码完成它所说的功能,并以更改代码的一部分不会影响其他部分的方式执行.
我希望您对BDD的愤怒感来自于您正在编写工具来简单地"消除错误"或"替换您的QA过程",BDD和TDD都不打算这样做.测试驱动开发意味着"开发,由测试驱动",而不是"测试,由开发驱动".在我看来,你想要后者.
集成测试和软件质量保证是完全不同的主题,但我理解这些与TDD与它们之间存在大量混淆的原因.
测试驱动开发意味着"开发,由测试驱动",而不是"测试,由开发驱动".在我看来,你想要后者.
更新只想分享关于这个问题的博客文章:在我之后重复:测试驱动开发是关于设计,而不是测试!
| 归档时间： |
|
| 查看次数： |
514 次 |
| 最近记录： |