tdd – 测试驱动开发“进入障碍”？

发布时间：2020-12-14 05:00:44 所属栏目：百科来源：网络整理

导读：我正在研究测试驱动开发,其中一个讨论点是与TDD相关的“入门障碍”.有没有人在这个领域有任何经验,你曾经做过的任何决定不使用TDD的项目,因为进入门槛太高了？从我可以看出,进入的唯一障碍是个体开发者的知识(以及经验),大多数人并不完全习惯于这个过程而且

我正在研究测试驱动开发,其中一个讨论点是与TDD相关的“入门障碍”.有没有人在这个领域有任何经验,你曾经做过的任何决定不使用TDD的项目,因为进入门槛太高了？

从我可以看出,进入的唯一障碍是个体开发者的知识(以及经验),大多数人并不完全习惯于这个过程而且有点陌生.在财务方面,由于大多数市场领先的工具都是开源的,免费提供,文档齐全且得到良好支持,因此它似乎非常具有吸引力.

思想/感受赞赏.

谢谢,

编辑 – 有谁知道任何高调引用人们提倡TDD？很想知道链条有多高.干杯.

解决方法

一些障碍包括：

>现有的代码库,不适合单元测试.>一个难以有意义地进行单元测试的问题域,例如GUI工作或与第三方系统的集成.>对单元问题的集成问题的感知(换句话说,如果它不能端到端地工作,它就不会做任何事情,那么测试单元的重点是什么).>一种想要提前设计并拥有清晰的系统设计而不是通过测试推动设计的思维方式>一种政治文化,其设计由与开发不同的人/团体完成,并且该设计不是单元测试友好的.>无法克服TDD不是为了测试一致性这一事实(诸如“编写测试的人不应该是编码测试的人,他们对自己过于宽容”这样的变体).>直到现在他们还没有编码,所以这种转变更难.>有时某个测试可能很难设置,因此该方法会因为“感觉”变慢而被放弃.>设计要求不能很好地适应不断发展的设计或根本不考虑(认为核电厂控制软件或其他系统的实际寿命取决于它们的正常运行).>如果每个人在检查代码之前没有运行测试,那么测试会因为错误的原因而开始经常中断(这是代码的预期行为发生了变化,但是测试没有跟上,所以测试是错误的,而不是代码)所以他们可以被视为拖累.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!