我正致力于将单元测试集成到我所在团队的开发过程中,有一些人对此持怀疑态度。有什么好方法可以让团队中持怀疑态度的开发人员相信单元测试的价值?在我的具体情况下,我们将在添加功能或修复错误时添加单元测试。不幸的是,我们的代码库并不容易进行测试。
当前回答
Yes - Unit Testing is definitely worth the effort but you should know it's not a silver bullet. Unit Testing is work and you will have to work to keep the test updated and relevant as code changes but the value offered is worth the effort you have to put in. The ability to refactor with impunity is a huge benefit as you can always validate functionality by running your tests after any change code. The trick is to not get too hung up on exactly the unit-of-work you're testing or how you are scaffolding test requirements and when a unit-test is really a functional test, etc. People will argue about this stuff for hours on end and the reality is that any testing you do as your write code is better than not doing it. The other axiom is about quality and not quantity - I have seen code-bases with 1000's of test that are essentially meaningless as the rest don't really test anything useful or anything domain specific like business rules, etc of the particular domain. I've also seen codebases with 30% code coverage but the tests were relevant, meaningful and really awesome as they tested the core functionality of the code it was written for and expressed how the code should be used.
在探索新的框架或代码库时,我最喜欢的一个技巧是为“它”编写单元测试,以发现事物是如何工作的。这是一个学习新事物的好方法,而不是阅读枯燥的文档:)
其他回答
单元测试的好处之一是可预测性。
在单元测试之前,我可以非常准确地预测编写代码所需的时间,但无法预测调试所需的时间。
现在,因为我可以计划将要编写什么测试,所以我知道编码需要多长时间,并且在编码结束时,系统已经调试好了!这为开发过程带来了可预见性,消除了许多压力,但仍然保留了所有的乐趣!!
偶尔,我自己或我的同事会花几个小时来研究一个不太明显的错误,一旦发现了错误的原因,90%的情况下代码都没有经过单元测试。单元测试并不存在,因为开发人员为了节省时间而偷工减料,但随后却失去了这一点和更多的调试。
花少量的时间来编写单元测试可以节省未来调试的时间。
让你测试的第一个东西与单元测试无关。我主要使用Perl工作,所以这些都是特定于Perl的示例,但您也可以适应。
每个模块是否正确加载和编译?在Perl中,这是一个创建Foo的问题。t对每个Foo。PM的代码库,它做: use_ok('Foo'); 所有的POD(普通文档)格式是否正确?使用Test::Pod来验证所有文件中所有Pod格式的有效性。
你可能不认为这些是大事情,他们不是,但我可以保证你会抓到一些泔水。当这些测试每小时运行一次,并捕捉到某人的过早提交时,您会让人们说“嘿,这很酷”。
这是非常以. net为中心的,但是有人尝试过Pex吗?
我非常怀疑,直到我尝试了——哇,多么精彩的表演。以前我想“我不会被这个概念说服,直到我明白它实际上对我有什么好处”。我只跑了一次就改变了主意,说:“我不在乎你怎么知道那里有致命异常的风险,但现在我知道我必须处理它”
也许这种行为唯一的缺点是它会标记所有事情,给你六个月的积压。但是,如果你有代码债,你总是有代码债,只是你不知道而已。告诉项目经理可能有20万个故障点,而你之前只知道有几十个,这是一个令人讨厌的前景,这意味着首先解释这个概念是至关重要的。
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.
推荐文章
- 为什么Visual Studio 2015/2017/2019测试运行器没有发现我的xUnit v2测试
- 单元测试反模式目录
- 类未找到:IntelliJ中的空测试套件
- Mockito的argumentCaptor的例子
- 单元测试:日期时间。现在
- 为什么单元测试中的代码不能找到包资源?
- 从导入的模块中模拟函数
- 在单元测试中设置HttpContext.Current.Session
- 何时使用Mockito.verify()?
- 在PHP单元测试执行期间,如何在CLI中输出?
- 单元测试的一些常用命名约定是什么?
- 如何直接从测试驱动程序调用自定义的Django manage.py命令?
- 如何重置笑话模拟函数调用计数之前,每次测试
- 在Python Django中运行单元测试时,如何禁用日志记录?
- 在子目录中测试Golang