大型企业是否使用模拟/存根?[关闭]

我见过TDD在大型项目上非常有效,特别是帮助我们控制遗留代码库。我也看到过大规模的敏捷工作,尽管我认为单独做敏捷实践是不够的。 Richard Durnall 写了一篇关于敏捷如何在公司中取得突破的伟大文章。我怀疑精益可能更适合在更高层次的组织。当然,如果到敏捷开始在多个项目中使用的时候,公司文化还不能很好地匹配它,那么它就不会起作用(但其他任何东西也不会起作用;最终你会遇到一个对任何一种变化都无法有效响应的公司)。

不管怎样,回到TDD…测试独立的代码单元有时会很棘手,如果涉及到一个大的数据驱动域对象,我通常不会嘲笑它。相反,我使用一个构建器模式来简化以正确方式设置域对象的过程。

如果域对象具有复杂的行为,我可能会嘲笑它,使其行为可以预测。

对我来说,编写单元测试的目的并不是真正用于回归测试。它帮助我思考代码的行为、它的职责以及它如何使用其他代码来帮助它完成它所做的工作。它为其他开发人员提供文档,并帮助我保持设计的整洁。我把它们看作是如何使用一段代码、为什么它有价值以及您可以从中期望的行为的例子。

通过这样的思考,我倾向于编写测试,使代码更容易和安全地更改,而不是将其固定下来,这样就没有人可以破坏它。我发现专注于模拟所有东西,特别是领域对象,会导致非常脆弱的测试。

TDD的目的是 不 测试。如果您想测试某个东西,可以让测试人员手动查看它。测试人员不能每次都这样做的唯一原因是因为我们不断地更改代码,所以TDD的目的是使代码更容易更改。如果你的TDD不能让事情变得更简单,那就找一种不同的方法来做。

我在模拟对象和单元测试项目中有过一些很好的经验,在这些项目中有很多前期设计和一个舒适的工作时间线——不幸的是,这通常是大多数公司无法承担风险的奢侈品。GTD和GTDF方法也确实没有帮助解决这个问题,因为它们让开发人员踏上了发布的跑步机。

单元测试的大问题是,如果你不从整个团队中购买,会发生的事情是,一个开发人员用玫瑰色的眼镜查看代码(并且没有自己的错误),只实现他们能想到的快乐路径测试。单元测试并不总是像他们应该做的那样被跟上,因为角落的箱子会溜过去,并不是每个人都喝了Kool Aid。测试和提出算法是一种非常不同的思维方式,许多开发人员真的不知道该怎么想。

当迭代和开发周期很紧时,我发现自己通过依赖静态分析工具和复杂性工具对代码质量获得了更多的信心。(findbugs、pmd、clang llvm等)即使它们位于无法直接寻址的区域,也可以将它们标记为地雷,帮助更好地确定在该区域实现新功能的风险。

如果您发现模拟/存根是痛苦的,需要很长时间,那么您可能有一个不是为单元测试而设计的设计。然后你要么重构,要么活下去。

我会重构。

我有一个很大的应用程序,在编写单元测试时没有遇到任何问题,而且当我知道该重构了。

当然,集成测试没有任何问题。实际上,我也有一些测试DAL或应用程序的其他部分。

所有的自动化测试都应该是一个整体,单元测试只是其中的一部分。

是的。 相当广泛。

这个 最困难的部分是让纪律到位来编写干净的代码 -以及(更困难的部分) 通过在执行过程中重构来消除错误代码的规则 .

我曾在世界上最大的银行之一工作,负责一个从纽约、伦敦、巴黎和东京使用的项目。它很好地使用了模拟,通过许多规则,我们有了非常干净的代码。

我怀疑模拟是问题所在——它们只是一个相当简单的工具。 如果你不得不过度依赖它们,比如说你需要模拟的模拟返回模拟-那么测试或代码就出了问题…