我正致力于将单元测试集成到我所在团队的开发过程中,有一些人对此持怀疑态度。有什么好方法可以让团队中持怀疑态度的开发人员相信单元测试的价值?在我的具体情况下,我们将在添加功能或修复错误时添加单元测试。不幸的是,我们的代码库并不容易进行测试。


当前回答

@George Stocker“不幸的是,我们的代码库并不适合简单的测试。”每个人都同意单元测试有好处,但对于这个代码库来说,成本似乎很高。如果成本大于收益,那么他们为什么要对此充满热情呢?倾听你同事的意见;也许对他们来说,单元测试的痛苦比单元测试的价值更大。

具体地说,尽量尽快获得价值,而不是一些感觉良好的“xUnit是绿色的”价值,而是用户和维护者所重视的干净代码。也许您必须为一次迭代强制进行单元测试,然后讨论是否值得这样做。

其他回答

单元测试可以帮助您以更少的错误发布软件,同时降低总体开发成本。您可以点击链接阅读更多关于单元测试的好处

关于这个话题,我写了一篇很大的博客文章。我发现单靠单元测试是不值得的,而且通常在截止日期临近时就会被削减。

与其从“测试后验证”的角度来讨论单元测试,我们应该看看在实现之前编写规范/测试/想法时所发现的真正价值。

这个简单的想法改变了我写软件的方式,我不会回到“旧的”方式。

测试优先开发如何改变了我的生活

我同意与大多数人相反的观点: 不编写单元测试是可以的 特别是重原型的编程(例如AI)很难与单元测试相结合。

单元测试的一个好处是,它们可以作为说明代码行为方式的文档。好的测试有点像参考实现,团队成员可以通过查看它们来了解如何将他们的代码与您的代码集成。

测试驱动开发中经常被忽略的一个主要部分是可测试代码的编写。乍一看,这似乎是一种妥协,但您会发现可测试代码最终也是模块化的、可维护的和可读的。 如果你仍然需要说服别人,这是一个关于单元测试优点的简单演示。