我正致力于将单元测试集成到我所在团队的开发过程中,有一些人对此持怀疑态度。有什么好方法可以让团队中持怀疑态度的开发人员相信单元测试的价值?在我的具体情况下,我们将在添加功能或修复错误时添加单元测试。不幸的是,我们的代码库并不容易进行测试。
当前回答
@George Stocker“不幸的是,我们的代码库并不适合简单的测试。”每个人都同意单元测试有好处,但对于这个代码库来说,成本似乎很高。如果成本大于收益,那么他们为什么要对此充满热情呢?倾听你同事的意见;也许对他们来说,单元测试的痛苦比单元测试的价值更大。
具体地说,尽量尽快获得价值,而不是一些感觉良好的“xUnit是绿色的”价值,而是用户和维护者所重视的干净代码。也许您必须为一次迭代强制进行单元测试,然后讨论是否值得这样做。
其他回答
单元测试的全部意义在于使测试变得简单。这是自动的。“make test”就完成了。如果您面临的问题之一是难以测试代码,那么这就是使用单元测试的最佳理由。
单元测试的一个好处是,它们可以作为说明代码行为方式的文档。好的测试有点像参考实现,团队成员可以通过查看它们来了解如何将他们的代码与您的代码集成。
就在今天,我不得不更改一个类,之前已经为其编写了单元测试。 测试本身写得很好,包括我甚至没有想过的测试场景。 幸运的是,所有测试都通过了,我的更改很快得到了验证,并自信地放到了测试环境中。
你应该尽量少测试!
这意味着,您应该编写足够多的单元测试来揭示意图。这一点经常被掩盖。单元测试的成本很高。如果您进行了更改,并且必须更改测试,那么您将不那么敏捷。保持单元测试短小精悍。这样它们就有很大的价值。
我经常看到许多永远不会崩溃的测试,它们又大又笨拙,没有提供太多价值,它们最终只会拖慢你的速度。
我同意与大多数人相反的观点: 不编写单元测试是可以的 特别是重原型的编程(例如AI)很难与单元测试相结合。
推荐文章
- 为什么Visual Studio 2015/2017/2019测试运行器没有发现我的xUnit v2测试
- 单元测试反模式目录
- 类未找到:IntelliJ中的空测试套件
- Mockito的argumentCaptor的例子
- 单元测试:日期时间。现在
- 为什么单元测试中的代码不能找到包资源?
- 从导入的模块中模拟函数
- 在单元测试中设置HttpContext.Current.Session
- 何时使用Mockito.verify()?
- 在PHP单元测试执行期间,如何在CLI中输出?
- 单元测试的一些常用命名约定是什么?
- 如何直接从测试驱动程序调用自定义的Django manage.py命令?
- 如何重置笑话模拟函数调用计数之前,每次测试
- 在Python Django中运行单元测试时,如何禁用日志记录?
- 在子目录中测试Golang