大企业是否利用嘲弄/存根？

Question

有没有人在一家大公司或一个非常大的项目上工作,成功地使用了单元测试？

我们当前的数据库有大约300个表,大约有100个根.总共有大约4000列,完成后我们将有大约200万行代码.我想知道 - 那些拥有这样大小(或更大)数据库的公司是否真的经历了Mock/Stub他们的域对象的测试工作？我在一家大公司工作已经两年了,但当时所有大型应用程序都是通过集成测试进行测试的.如果需要进行大量设置,则单元测试通常不受欢迎.

我开始觉得单元测试对于除静态方法之外的任何事情都是浪费时间,因为许多我们的测试方法需要比实际代码更长或更长的时间...特别是设置/安排步骤.更糟糕的是,我们的一位开发人员一直在引用肯特贝克克莱斯勒项目中单元测试和敏捷方法如此严重失败......而且这种方法并不是一种可以很好地扩展的方法论.

任何参考或经验都会很棒.管理层喜欢单元测试的想法,但如果他们看到我们正在编写的额外代码(以及我们的挫败感),他们会乐意退缩.

Answer 1

我已经看到 TDD 在大型项目中运行得非常好，特别是帮助我们控制遗留代码库。我也看到过大规模的敏捷工作，尽管我认为仅进行敏捷实践是不够的。Richard Durnall写了一篇很棒的文章，讲述了随着敏捷的发展，公司中的事情是如何发生变化的。我怀疑精益可能更适合组织中的更高级别。当然，如果当敏捷开始在多个项目中使用时，公司文化与敏捷不匹配，那么它就行不通（但其他任何东西也行不通；你最终会得到一家无法有效响应变革的公司）无论哪种方式）。

无论如何，回到 TDD...测试独立的代码单元有时可能很棘手，如果涉及大数据驱动的域对象，我经常不会模拟它。相反，我使用构建器模式来轻松以正确的方式设置该域对象。

如果域对象具有复杂的行为，我可能会模拟它，以便它的行为可预测。

对我来说，编写单元测试的目的并不是真正为了回归测试。它帮助我思考代码的行为、它的职责以及它如何使用其他代码片段来帮助它完成它所做的事情。它为其他开发人员提供文档，并帮助我保持设计简洁。我认为它们是如何使用一段代码、为什么它有价值以及您可以期望它的行为类型的示例。

通过以这种方式思考它们，我倾向于编写使代码易于且安全地更改的测试，而不是固定它以便没有人可以破坏它。我发现专注于模拟所有内容，尤其是域对象，可能会导致相当脆弱的测试。

TDD 的目的不是测试。如果您想测试某些东西，您可以让测试人员手动查看它。测试人员不能每次都这样做的唯一原因是因为我们不断更改代码，所以 TDD 的目的是使代码易于更改。如果您的 TDD 没有让事情变得更容易，请寻找不同的方法来做到这一点。