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


当前回答

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

其他回答

我曾多次尝试单元测试,我仍然相信,考虑到我的情况,这是值得的。

我开发网站,其中很多逻辑涉及在数据库中创建、检索或更新数据。当我为了单元测试的目的而尝试“模拟”数据库时,它变得非常混乱,似乎有点毫无意义。

当我围绕业务逻辑编写单元测试时,从长远来看它从未真正帮助过我。因为我主要独自从事项目工作,我倾向于直观地知道哪些代码区域可能会受到我所从事的工作的影响,并且我手动测试这些区域。我希望尽可能快地向客户交付解决方案,而单元测试通常看起来是浪费时间。我列出了手动测试,并亲自完成它们,并在执行过程中标记它们。

我可以看到,当一个开发团队在一个项目中工作并互相更新代码时,这可能是有益的,但即使这样,我认为如果开发人员具有高质量,良好的沟通和编写良好的代码通常就足够了。

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

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

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

还没有人提到的一件事是,让所有开发人员承诺实际运行和更新任何现有的自动化测试。当您重新进行自动化测试并发现由于新的开发而出现故障时,会失去很多价值并使自动化测试非常痛苦。因为开发人员已经手动测试了代码,所以大多数测试不会指出错误,所以花在更新它们上的时间只是浪费。

说服怀疑者不要破坏其他人在单元测试上所做的工作,对于从测试中获得价值更为重要,而且可能更容易。

每次从存储库更新时,花费数小时更新由于新特性而损坏的测试既没有效率也没有乐趣。

作为一名物理专业的学生,我非常有动力去证明我的代码是可以正常工作的。您可以从逻辑上证明这一点,随着实现变得更加复杂,难度会急剧增加,或者您可以通过良好的测试对功能进行(尽可能接近的)经验证明。

如果不提供函数的逻辑证明,就必须进行测试。唯一的选择是说“我认为代码可以工作....”

如果您现有的代码库本身不适合单元测试,并且它已经处于生产环境中,那么通过试图重构所有代码以使其具有单元可测试性,您可能会产生比解决更多的问题。

您最好将精力放在改进集成测试上。有很多代码在没有单元测试的情况下编写起来更简单,如果QA可以根据需求文档验证功能,那么就完成了。船。

在我的脑海中,最经典的例子就是嵌入到GridView的ASPX页面中的SqlDataReader。代码都在ASPX文件中。SQL位于存储过程中。你做什么单元测试?如果页面做了它应该做的事情,那么是否真的应该将其重新设计成几个层,以便实现自动化?