我正致力于将单元测试集成到我所在团队的开发过程中,有一些人对此持怀疑态度。有什么好方法可以让团队中持怀疑态度的开发人员相信单元测试的价值?在我的具体情况下,我们将在添加功能或修复错误时添加单元测试。不幸的是,我们的代码库并不容易进行测试。
当前回答
单元测试绝对是值得付出努力的。不幸的是,您选择了一个困难的(但不幸的是常见的)场景来实现它。
从单元测试中获得的最大好处是从头开始使用它——在一些精选的小项目中,我有幸在实现类之前编写单元测试(此时接口已经完成)。通过适当的单元测试,您可以在类还处于婴儿期时就发现并修复它们,而不是在将来毫无疑问会集成到复杂系统中的任何地方。
如果您的软件是完全面向对象的,那么您应该能够在类级别上添加单元测试,而不需要太多的努力。如果您没有那么幸运,您仍然应该尽可能地尝试合并单元测试。确保当你添加新功能时,新部分都有清晰的接口,你会发现单元测试让你的工作变得更容易。
其他回答
我是一名维护工程师,负责一个文档记录不佳、糟糕而庞大的代码库。我希望编写代码的人已经为它编写了单元测试。 每次我进行更改和更新产品代码时,我都担心自己可能会因为没有考虑某些条件而引入错误。 如果他们编写测试,那么对代码库的更改就会更容易、更快。(与此同时,代码库将处于更好的状态)..
我认为,在编写api或框架时,单元测试非常有用,因为这些api或框架必须持续多年,并由原始编码器以外的人使用/修改/发展。
单元测试非常值得最初的投资。自从几年前开始使用单元测试以来,我发现了一些真正的好处:
回归测试消除了恐惧 对代码进行更改(什么都没有 就像看到代码的温暖光芒 每次有变化,要么工作,要么爆发 了) 以下的可执行代码示例 其他团队成员(包括你自己) 6个月的时间…) 无情的重构——这是令人难以置信的回报,试试吧!
代码片段可以极大地帮助减少创建测试的开销。创建能够在几秒钟内创建类大纲和相关单元测试fixture的代码片段并不困难。
我不知道。很多地方不做单元测试,但是代码质量很好。微软做单元测试,但是比尔·盖茨在他的演示中出现了蓝屏。
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