我正致力于将单元测试集成到我所在团队的开发过程中,有一些人对此持怀疑态度。有什么好方法可以让团队中持怀疑态度的开发人员相信单元测试的价值?在我的具体情况下,我们将在添加功能或修复错误时添加单元测试。不幸的是,我们的代码库并不容易进行测试。
当前回答
如果您现有的代码库本身不适合单元测试,并且它已经处于生产环境中,那么通过试图重构所有代码以使其具有单元可测试性,您可能会产生比解决更多的问题。
您最好将精力放在改进集成测试上。有很多代码在没有单元测试的情况下编写起来更简单,如果QA可以根据需求文档验证功能,那么就完成了。船。
在我的脑海中,最经典的例子就是嵌入到GridView的ASPX页面中的SqlDataReader。代码都在ASPX文件中。SQL位于存储过程中。你做什么单元测试?如果页面做了它应该做的事情,那么是否真的应该将其重新设计成几个层,以便实现自动化?
其他回答
单元测试的一个好处是,它们可以作为说明代码行为方式的文档。好的测试有点像参考实现,团队成员可以通过查看它们来了解如何将他们的代码与您的代码集成。
单元测试的全部意义在于使测试变得简单。这是自动的。“make test”就完成了。如果您面临的问题之一是难以测试代码,那么这就是使用单元测试的最佳理由。
偶尔,我自己或我的同事会花几个小时来研究一个不太明显的错误,一旦发现了错误的原因,90%的情况下代码都没有经过单元测试。单元测试并不存在,因为开发人员为了节省时间而偷工减料,但随后却失去了这一点和更多的调试。
花少量的时间来编写单元测试可以节省未来调试的时间。
最好的说服方式是……找到一个bug,为它写一个单元测试,修复这个bug。
这个特定的错误不太可能再次出现,您可以通过测试来证明它。
如果你做得足够多,其他人很快就会明白。
我同意与大多数人相反的观点: 不编写单元测试是可以的 特别是重原型的编程(例如AI)很难与单元测试相结合。
推荐文章
- 为什么Visual Studio 2015/2017/2019测试运行器没有发现我的xUnit v2测试
- 单元测试反模式目录
- 类未找到:IntelliJ中的空测试套件
- Mockito的argumentCaptor的例子
- 单元测试:日期时间。现在
- 为什么单元测试中的代码不能找到包资源?
- 从导入的模块中模拟函数
- 在单元测试中设置HttpContext.Current.Session
- 何时使用Mockito.verify()?
- 在PHP单元测试执行期间,如何在CLI中输出?
- 单元测试的一些常用命名约定是什么?
- 如何直接从测试驱动程序调用自定义的Django manage.py命令?
- 如何重置笑话模拟函数调用计数之前,每次测试
- 在Python Django中运行单元测试时,如何禁用日志记录?
- 在子目录中测试Golang