我正致力于将单元测试集成到我所在团队的开发过程中,有一些人对此持怀疑态度。有什么好方法可以让团队中持怀疑态度的开发人员相信单元测试的价值?在我的具体情况下,我们将在添加功能或修复错误时添加单元测试。不幸的是,我们的代码库并不容易进行测试。
当前回答
你应该尽量少测试!
这意味着,您应该编写足够多的单元测试来揭示意图。这一点经常被掩盖。单元测试的成本很高。如果您进行了更改,并且必须更改测试,那么您将不那么敏捷。保持单元测试短小精悍。这样它们就有很大的价值。
我经常看到许多永远不会崩溃的测试,它们又大又笨拙,没有提供太多价值,它们最终只会拖慢你的速度。
其他回答
最好的说服方式是……找到一个bug,为它写一个单元测试,修复这个bug。
这个特定的错误不太可能再次出现,您可以通过测试来证明它。
如果你做得足够多,其他人很快就会明白。
如果您现有的代码库本身不适合单元测试,并且它已经处于生产环境中,那么通过试图重构所有代码以使其具有单元可测试性,您可能会产生比解决更多的问题。
您最好将精力放在改进集成测试上。有很多代码在没有单元测试的情况下编写起来更简单,如果QA可以根据需求文档验证功能,那么就完成了。船。
在我的脑海中,最经典的例子就是嵌入到GridView的ASPX页面中的SqlDataReader。代码都在ASPX文件中。SQL位于存储过程中。你做什么单元测试?如果页面做了它应该做的事情,那么是否真的应该将其重新设计成几个层,以便实现自动化?
让你测试的第一个东西与单元测试无关。我主要使用Perl工作,所以这些都是特定于Perl的示例,但您也可以适应。
每个模块是否正确加载和编译?在Perl中,这是一个创建Foo的问题。t对每个Foo。PM的代码库,它做: use_ok('Foo'); 所有的POD(普通文档)格式是否正确?使用Test::Pod来验证所有文件中所有Pod格式的有效性。
你可能不认为这些是大事情,他们不是,但我可以保证你会抓到一些泔水。当这些测试每小时运行一次,并捕捉到某人的过早提交时,您会让人们说“嘿,这很酷”。
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.
在探索新的框架或代码库时,我最喜欢的一个技巧是为“它”编写单元测试,以发现事物是如何工作的。这是一个学习新事物的好方法,而不是阅读枯燥的文档:)
当你说“我们的代码库不适合简单的测试”时,这是代码气味的第一个迹象。编写单元测试意味着您通常以不同的方式编写代码,以使代码更具可测试性。在我看来,这是一件好事,因为多年来我在编写代码时看到我必须为其编写测试,这迫使我提出更好的设计。
推荐文章
- 为什么Visual Studio 2015/2017/2019测试运行器没有发现我的xUnit v2测试
- 单元测试反模式目录
- 类未找到:IntelliJ中的空测试套件
- Mockito的argumentCaptor的例子
- 单元测试:日期时间。现在
- 为什么单元测试中的代码不能找到包资源?
- 从导入的模块中模拟函数
- 在单元测试中设置HttpContext.Current.Session
- 何时使用Mockito.verify()?
- 在PHP单元测试执行期间,如何在CLI中输出?
- 单元测试的一些常用命名约定是什么?
- 如何直接从测试驱动程序调用自定义的Django manage.py命令?
- 如何重置笑话模拟函数调用计数之前,每次测试
- 在Python Django中运行单元测试时,如何禁用日志记录?
- 在子目录中测试Golang