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


当前回答

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

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

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

其他回答

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

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

当你说“我们的代码库不适合简单的测试”时,这是代码气味的第一个迹象。编写单元测试意味着您通常以不同的方式编写代码,以使代码更具可测试性。在我看来,这是一件好事,因为多年来我在编写代码时看到我必须为其编写测试,这迫使我提出更好的设计。

单元测试的全部意义在于使测试变得简单。这是自动的。“make test”就完成了。如果您面临的问题之一是难以测试代码,那么这就是使用单元测试的最佳理由。

我在几年前发现了TDD,从那时起我就使用它编写了所有我喜欢的项目。我估计,TDD一个项目所花费的时间与牛仔式地组合一个项目所花费的时间大致相同,但我对最终产品的信心增加了,以至于我忍不住有一种成就感。

我还觉得它改进了我的设计风格(更面向界面,以防我需要一起模拟东西),而且,正如顶部的绿色帖子所写的,它有助于“编码便秘”:当你不知道接下来要写什么,或者你有一个令人生畏的任务摆在你面前时,你可以写小一点的。

最后,我发现到目前为止,TDD最有用的应用是在调试中,如果仅仅因为您已经开发了一个询问框架,那么您就可以用它来刺激项目以可重复的方式产生错误。