我正致力于将单元测试集成到我所在团队的开发过程中,有一些人对此持怀疑态度。有什么好方法可以让团队中持怀疑态度的开发人员相信单元测试的价值?在我的具体情况下,我们将在添加功能或修复错误时添加单元测试。不幸的是,我们的代码库并不容易进行测试。
当前回答
当涉及到重构或重写一段代码时,单元测试也特别有用。如果您有良好的单元测试覆盖率,您就可以满怀信心地进行重构。如果没有单元测试,通常很难确保您没有破坏任何东西。
其他回答
当您手动测试软件时,通常会使用一小组测试/操作。最终,您将自动修改输入数据或操作,以便围绕已知问题进行导航。应该有单元测试来提醒您某些事情不能正常工作。
我建议在编写代码之前编写测试,添加新的测试/数据来改进主代码的功能!
关于单元测试要记住的一件事是,它对开发人员来说是一种安慰。
相反,功能测试是针对用户的:无论何时添加功能测试,您都是在测试用户将看到的东西。当您添加单元测试时,您只是让开发人员的生活更轻松。在这方面有点奢侈。
当您必须在编写单元或功能测试之间做出选择时,请记住这种二分法。
根据我的经验,在复杂的软件环境中,单元测试和集成测试是“必须的”。
为了说服团队中的开发人员编写单元测试,您可能需要考虑在开发环境中集成单元测试回归分析(例如,在您的日常构建过程中)。
一旦开发人员知道如果单元测试失败,他们就不必花那么多时间调试它来发现问题,他们就会更有动力去编写这些测试。
这里有一个工具可以提供这样的功能:
单元测试回归分析工具
如果你正在使用NUnit,一个简单而有效的演示就是在他们面前运行NUnit自己的测试套件。看到一个真正的测试套件对代码库进行测试,胜过千言万语……
如果您现有的代码库本身不适合单元测试,并且它已经处于生产环境中,那么通过试图重构所有代码以使其具有单元可测试性,您可能会产生比解决更多的问题。
您最好将精力放在改进集成测试上。有很多代码在没有单元测试的情况下编写起来更简单,如果QA可以根据需求文档验证功能,那么就完成了。船。
在我的脑海中,最经典的例子就是嵌入到GridView的ASPX页面中的SqlDataReader。代码都在ASPX文件中。SQL位于存储过程中。你做什么单元测试?如果页面做了它应该做的事情,那么是否真的应该将其重新设计成几个层,以便实现自动化?
推荐文章
- 为什么Visual Studio 2015/2017/2019测试运行器没有发现我的xUnit v2测试
- 单元测试反模式目录
- 类未找到:IntelliJ中的空测试套件
- Mockito的argumentCaptor的例子
- 单元测试:日期时间。现在
- 为什么单元测试中的代码不能找到包资源?
- 从导入的模块中模拟函数
- 在单元测试中设置HttpContext.Current.Session
- 何时使用Mockito.verify()?
- 在PHP单元测试执行期间,如何在CLI中输出?
- 单元测试的一些常用命名约定是什么?
- 如何直接从测试驱动程序调用自定义的Django manage.py命令?
- 如何重置笑话模拟函数调用计数之前,每次测试
- 在Python Django中运行单元测试时,如何禁用日志记录?
- 在子目录中测试Golang