我正致力于将单元测试集成到我所在团队的开发过程中,有一些人对此持怀疑态度。有什么好方法可以让团队中持怀疑态度的开发人员相信单元测试的价值?在我的具体情况下,我们将在添加功能或修复错误时添加单元测试。不幸的是,我们的代码库并不容易进行测试。
当前回答
根据我的经验,在复杂的软件环境中,单元测试和集成测试是“必须的”。
为了说服团队中的开发人员编写单元测试,您可能需要考虑在开发环境中集成单元测试回归分析(例如,在您的日常构建过程中)。
一旦开发人员知道如果单元测试失败,他们就不必花那么多时间调试它来发现问题,他们就会更有动力去编写这些测试。
这里有一个工具可以提供这样的功能:
单元测试回归分析工具
其他回答
One of the best things about unit testing is that your code will become easier to test as you do it. Preexisting code created without tests is always a challenge because since they weren't meant to be unit-tested, it's not rare to have a high level of coupling between classes, hard-to-configure objects inside your class - like an e-mail sending service reference - and so on. But don't let this bring you down! You'll see that your overall code design will become better as you start to write unit-tests, and the more you test, the more confident you'll become on making even more changes to it without fear of breaking you application or introducing bugs.
There are several reasons to unit-test your code, but as time progresses, you'll find out that the time you save on testing is one of the best reasons to do it. In a system I've just delivered, I insisted on doing automated unit-testing in spite of the claims that I'd spend way more time doing the tests than I would by testing the system manually. With all my unit tests done, I run more than 400 test cases in less than 10 minutes, and every time I had to do a small change in the code, all it took me to be sure the code was still working without bugs was ten minutes. Can you imagine the time one would spend to run those 400+ test cases by hand?
当涉及到自动化测试——无论是单元测试还是验收测试——每个人都认为编写可以手动完成的代码是浪费精力,有时这是真的——如果你计划只运行一次测试的话。自动化测试最好的部分是,您可以毫不费力地运行它们几次,并且在第二次或第三次运行之后,您所浪费的时间和精力已经得到了补偿。
最后一个建议是,不仅要对代码进行单元测试,还要先进行测试(详见TDD和BDD)。
[我有一个观点,我不能在上面看到]
“每个人都在进行单元测试,他们不一定意识到这一点——事实”
想想看,你写了一个函数来解析一个字符串并删除新的行字符。作为一个开发新手,你要么在命令行中通过Main()实现它来运行几个用例,要么用一个按钮组合一个可视化前端,将你的函数绑定到几个文本框和一个按钮上,然后看看会发生什么。
这就是单元测试——基本的和糟糕的组合在一起,但是你测试了一些情况下的代码段。
你写一些更复杂的东西。当您抛出一些用例(单元测试)并将其调试到代码中并进行跟踪时,它会抛出错误。你在浏览过程中查看这些值,并决定它们是对还是错。在某种程度上,这是单元测试。
这里的单元测试实际上是采用这种行为,将其形式化为结构化模式并保存,以便您可以轻松地重新运行这些测试。如果您编写了一个“适当的”单元测试用例而不是手动测试,那么它所花费的时间是相同的,或者随着您的经验的增加可能会更少,并且您可以一次又一次地重复它
单元测试可以帮助您以更少的错误发布软件,同时降低总体开发成本。您可以点击链接阅读更多关于单元测试的好处
让你测试的第一个东西与单元测试无关。我主要使用Perl工作,所以这些都是特定于Perl的示例,但您也可以适应。
每个模块是否正确加载和编译?在Perl中,这是一个创建Foo的问题。t对每个Foo。PM的代码库,它做: use_ok('Foo'); 所有的POD(普通文档)格式是否正确?使用Test::Pod来验证所有文件中所有Pod格式的有效性。
你可能不认为这些是大事情,他们不是,但我可以保证你会抓到一些泔水。当这些测试每小时运行一次,并捕捉到某人的过早提交时,您会让人们说“嘿,这很酷”。
单元测试绝对是值得付出努力的。不幸的是,您选择了一个困难的(但不幸的是常见的)场景来实现它。
从单元测试中获得的最大好处是从头开始使用它——在一些精选的小项目中,我有幸在实现类之前编写单元测试(此时接口已经完成)。通过适当的单元测试,您可以在类还处于婴儿期时就发现并修复它们,而不是在将来毫无疑问会集成到复杂系统中的任何地方。
如果您的软件是完全面向对象的,那么您应该能够在类级别上添加单元测试,而不需要太多的努力。如果您没有那么幸运,您仍然应该尽可能地尝试合并单元测试。确保当你添加新功能时,新部分都有清晰的接口,你会发现单元测试让你的工作变得更容易。
推荐文章
- 为什么Visual Studio 2015/2017/2019测试运行器没有发现我的xUnit v2测试
- 单元测试反模式目录
- 类未找到:IntelliJ中的空测试套件
- Mockito的argumentCaptor的例子
- 单元测试:日期时间。现在
- 为什么单元测试中的代码不能找到包资源?
- 从导入的模块中模拟函数
- 在单元测试中设置HttpContext.Current.Session
- 何时使用Mockito.verify()?
- 在PHP单元测试执行期间,如何在CLI中输出?
- 单元测试的一些常用命名约定是什么?
- 如何直接从测试驱动程序调用自定义的Django manage.py命令?
- 如何重置笑话模拟函数调用计数之前,每次测试
- 在Python Django中运行单元测试时,如何禁用日志记录?
- 在子目录中测试Golang