我正致力于将单元测试集成到我所在团队的开发过程中,有一些人对此持怀疑态度。有什么好方法可以让团队中持怀疑态度的开发人员相信单元测试的价值?在我的具体情况下,我们将在添加功能或修复错误时添加单元测试。不幸的是,我们的代码库并不容易进行测试。
当前回答
根据我的经验,在复杂的软件环境中,单元测试和集成测试是“必须的”。
为了说服团队中的开发人员编写单元测试,您可能需要考虑在开发环境中集成单元测试回归分析(例如,在您的日常构建过程中)。
一旦开发人员知道如果单元测试失败,他们就不必花那么多时间调试它来发现问题,他们就会更有动力去编写这些测试。
这里有一个工具可以提供这样的功能:
单元测试回归分析工具
其他回答
测试驱动开发中经常被忽略的一个主要部分是可测试代码的编写。乍一看,这似乎是一种妥协,但您会发现可测试代码最终也是模块化的、可维护的和可读的。 如果你仍然需要说服别人,这是一个关于单元测试优点的简单演示。
单元测试的一个好处是,它们可以作为说明代码行为方式的文档。好的测试有点像参考实现,团队成员可以通过查看它们来了解如何将他们的代码与您的代码集成。
最好的说服方式是……找到一个bug,为它写一个单元测试,修复这个bug。
这个特定的错误不太可能再次出现,您可以通过测试来证明它。
如果你做得足够多,其他人很快就会明白。
单元测试的好处之一是可预测性。
在单元测试之前,我可以非常准确地预测编写代码所需的时间,但无法预测调试所需的时间。
现在,因为我可以计划将要编写什么测试,所以我知道编码需要多长时间,并且在编码结束时,系统已经调试好了!这为开发过程带来了可预见性,消除了许多压力,但仍然保留了所有的乐趣!!
Unit testing helps a lot in projects that are larger than any one developer can hold in their head. They allow you to run the unit test suite before checkin and discover if you broke something. This cuts down a lot on instances of having to sit and twiddle your thumbs while waiting for someone else to fix a bug they checked in, or going to the hassle of reverting their change so you can get some work done. It's also immensely valuable in refactoring, so you can be sure that the refactored code passes all the tests that the original code did.
推荐文章
- 使用Moq验证特定参数
- 如何为python模块的argparse部分编写测试?
- python中的assertEquals和assertEqual
- 使用Mockito测试抽象类
- 使用Moq模拟单元测试的异步方法
- 你的项目没有引用“. net framework,Version=v4.6.2”框架。在“TargetFrameworks”中添加对“.NETFramework,Version=v4.6.2”的引用
- 使用Moq模拟扩展方法
- 基于输入参数模拟python函数
- 用于单元测试的NUnit vs. Visual Studio 2008测试项目
- 在使用信号时,你不能在'原子'块的末尾执行查询,但只能在单元测试期间执行
- .NET核心单元测试-模拟IOptions<T>
- 如何使用JUnit来测试异步进程
- 获取JUnit 4中当前正在执行的测试的名称
- 2个JUnit Assert类之间的区别
- 覆盖默认的Spring-Boot应用程序。属性设置在Junit测试