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


当前回答

单元测试绝对是值得付出努力的。不幸的是,您选择了一个困难的(但不幸的是常见的)场景来实现它。

从单元测试中获得的最大好处是从头开始使用它——在一些精选的小项目中,我有幸在实现类之前编写单元测试(此时接口已经完成)。通过适当的单元测试,您可以在类还处于婴儿期时就发现并修复它们,而不是在将来毫无疑问会集成到复杂系统中的任何地方。

如果您的软件是完全面向对象的,那么您应该能够在类级别上添加单元测试,而不需要太多的努力。如果您没有那么幸运,您仍然应该尽可能地尝试合并单元测试。确保当你添加新功能时,新部分都有清晰的接口,你会发现单元测试让你的工作变得更容易。

其他回答

如果你正在使用NUnit,一个简单而有效的演示就是在他们面前运行NUnit自己的测试套件。看到一个真正的测试套件对代码库进行测试,胜过千言万语……

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

让你测试的第一个东西与单元测试无关。我主要使用Perl工作,所以这些都是特定于Perl的示例,但您也可以适应。

每个模块是否正确加载和编译?在Perl中,这是一个创建Foo的问题。t对每个Foo。PM的代码库,它做: use_ok('Foo'); 所有的POD(普通文档)格式是否正确?使用Test::Pod来验证所有文件中所有Pod格式的有效性。

你可能不认为这些是大事情,他们不是,但我可以保证你会抓到一些泔水。当这些测试每小时运行一次,并捕捉到某人的过早提交时,您会让人们说“嘿,这很酷”。

单元测试的好处之一是可预测性。

在单元测试之前,我可以非常准确地预测编写代码所需的时间,但无法预测调试所需的时间。

现在,因为我可以计划将要编写什么测试,所以我知道编码需要多长时间,并且在编码结束时,系统已经调试好了!这为开发过程带来了可预见性,消除了许多压力,但仍然保留了所有的乐趣!!

最好的说服方式是……找到一个bug,为它写一个单元测试,修复这个bug。

这个特定的错误不太可能再次出现,您可以通过测试来证明它。

如果你做得足够多,其他人很快就会明白。