我正致力于将单元测试集成到我所在团队的开发过程中,有一些人对此持怀疑态度。有什么好方法可以让团队中持怀疑态度的开发人员相信单元测试的价值?在我的具体情况下,我们将在添加功能或修复错误时添加单元测试。不幸的是,我们的代码库并不容易进行测试。
当前回答
最好的说服方式是……找到一个bug,为它写一个单元测试,修复这个bug。
这个特定的错误不太可能再次出现,您可以通过测试来证明它。
如果你做得足够多,其他人很快就会明白。
其他回答
最好的说服方式是……找到一个bug,为它写一个单元测试,修复这个bug。
这个特定的错误不太可能再次出现,您可以通过测试来证明它。
如果你做得足够多,其他人很快就会明白。
还没有人提到的一件事是,让所有开发人员承诺实际运行和更新任何现有的自动化测试。当您重新进行自动化测试并发现由于新的开发而出现故障时,会失去很多价值并使自动化测试非常痛苦。因为开发人员已经手动测试了代码,所以大多数测试不会指出错误,所以花在更新它们上的时间只是浪费。
说服怀疑者不要破坏其他人在单元测试上所做的工作,对于从测试中获得价值更为重要,而且可能更容易。
每次从存储库更新时,花费数小时更新由于新特性而损坏的测试既没有效率也没有乐趣。
你应该尽量少测试!
这意味着,您应该编写足够多的单元测试来揭示意图。这一点经常被掩盖。单元测试的成本很高。如果您进行了更改,并且必须更改测试,那么您将不那么敏捷。保持单元测试短小精悍。这样它们就有很大的价值。
我经常看到许多永远不会崩溃的测试,它们又大又笨拙,没有提供太多价值,它们最终只会拖慢你的速度。
当你说“我们的代码库不适合简单的测试”时,这是代码气味的第一个迹象。编写单元测试意味着您通常以不同的方式编写代码,以使代码更具可测试性。在我看来,这是一件好事,因为多年来我在编写代码时看到我必须为其编写测试,这迫使我提出更好的设计。
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)。
推荐文章
- 为什么Visual Studio 2015/2017/2019测试运行器没有发现我的xUnit v2测试
- 单元测试反模式目录
- 类未找到:IntelliJ中的空测试套件
- Mockito的argumentCaptor的例子
- 单元测试:日期时间。现在
- 为什么单元测试中的代码不能找到包资源?
- 从导入的模块中模拟函数
- 在单元测试中设置HttpContext.Current.Session
- 何时使用Mockito.verify()?
- 在PHP单元测试执行期间,如何在CLI中输出?
- 单元测试的一些常用命名约定是什么?
- 如何直接从测试驱动程序调用自定义的Django manage.py命令?
- 如何重置笑话模拟函数调用计数之前,每次测试
- 在Python Django中运行单元测试时,如何禁用日志记录?
- 在子目录中测试Golang