我正致力于将单元测试集成到我所在团队的开发过程中,有一些人对此持怀疑态度。有什么好方法可以让团队中持怀疑态度的开发人员相信单元测试的价值?在我的具体情况下,我们将在添加功能或修复错误时添加单元测试。不幸的是,我们的代码库并不容易进行测试。
当前回答
我是一名维护工程师,负责一个文档记录不佳、糟糕而庞大的代码库。我希望编写代码的人已经为它编写了单元测试。 每次我进行更改和更新产品代码时,我都担心自己可能会因为没有考虑某些条件而引入错误。 如果他们编写测试,那么对代码库的更改就会更容易、更快。(与此同时,代码库将处于更好的状态)..
我认为,在编写api或框架时,单元测试非常有用,因为这些api或框架必须持续多年,并由原始编码器以外的人使用/修改/发展。
其他回答
最好的说服方式是……找到一个bug,为它写一个单元测试,修复这个bug。
这个特定的错误不太可能再次出现,您可以通过测试来证明它。
如果你做得足够多,其他人很快就会明白。
单元测试的全部意义在于使测试变得简单。这是自动的。“make test”就完成了。如果您面临的问题之一是难以测试代码,那么这就是使用单元测试的最佳理由。
关于这个话题,我写了一篇很大的博客文章。我发现单靠单元测试是不值得的,而且通常在截止日期临近时就会被削减。
与其从“测试后验证”的角度来讨论单元测试,我们应该看看在实现之前编写规范/测试/想法时所发现的真正价值。
这个简单的想法改变了我写软件的方式,我不会回到“旧的”方式。
测试优先开发如何改变了我的生活
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.
这是非常以. net为中心的,但是有人尝试过Pex吗?
我非常怀疑,直到我尝试了——哇,多么精彩的表演。以前我想“我不会被这个概念说服,直到我明白它实际上对我有什么好处”。我只跑了一次就改变了主意,说:“我不在乎你怎么知道那里有致命异常的风险,但现在我知道我必须处理它”
也许这种行为唯一的缺点是它会标记所有事情,给你六个月的积压。但是,如果你有代码债,你总是有代码债,只是你不知道而已。告诉项目经理可能有20万个故障点,而你之前只知道有几十个,这是一个令人讨厌的前景,这意味着首先解释这个概念是至关重要的。
推荐文章
- 为什么Visual Studio 2015/2017/2019测试运行器没有发现我的xUnit v2测试
- 单元测试反模式目录
- 类未找到:IntelliJ中的空测试套件
- Mockito的argumentCaptor的例子
- 单元测试:日期时间。现在
- 为什么单元测试中的代码不能找到包资源?
- 从导入的模块中模拟函数
- 在单元测试中设置HttpContext.Current.Session
- 何时使用Mockito.verify()?
- 在PHP单元测试执行期间,如何在CLI中输出?
- 单元测试的一些常用命名约定是什么?
- 如何直接从测试驱动程序调用自定义的Django manage.py命令?
- 如何重置笑话模拟函数调用计数之前,每次测试
- 在Python Django中运行单元测试时,如何禁用日志记录?
- 在子目录中测试Golang