我正致力于将单元测试集成到我所在团队的开发过程中,有一些人对此持怀疑态度。有什么好方法可以让团队中持怀疑态度的开发人员相信单元测试的价值?在我的具体情况下,我们将在添加功能或修复错误时添加单元测试。不幸的是,我们的代码库并不容易进行测试。
当前回答
当您手动测试软件时,通常会使用一小组测试/操作。最终,您将自动修改输入数据或操作,以便围绕已知问题进行导航。应该有单元测试来提醒您某些事情不能正常工作。
我建议在编写代码之前编写测试,添加新的测试/数据来改进主代码的功能!
其他回答
[我有一个观点,我不能在上面看到]
“每个人都在进行单元测试,他们不一定意识到这一点——事实”
想想看,你写了一个函数来解析一个字符串并删除新的行字符。作为一个开发新手,你要么在命令行中通过Main()实现它来运行几个用例,要么用一个按钮组合一个可视化前端,将你的函数绑定到几个文本框和一个按钮上,然后看看会发生什么。
这就是单元测试——基本的和糟糕的组合在一起,但是你测试了一些情况下的代码段。
你写一些更复杂的东西。当您抛出一些用例(单元测试)并将其调试到代码中并进行跟踪时,它会抛出错误。你在浏览过程中查看这些值,并决定它们是对还是错。在某种程度上,这是单元测试。
这里的单元测试实际上是采用这种行为,将其形式化为结构化模式并保存,以便您可以轻松地重新运行这些测试。如果您编写了一个“适当的”单元测试用例而不是手动测试,那么它所花费的时间是相同的,或者随着您的经验的增加可能会更少,并且您可以一次又一次地重复它
Unit Testing is one of the most adopted methodologies for high quality code. Its contribution to a more stable, independent and documented code is well proven . Unit test code is considered and handled as an a integral part of your repository, and as such requires development and maintenance. However, developers often encounter a situation where the resources invested in unit tests where not as fruitful as one would expect. In an ideal world every method we code will have a series of tests covering it’s code and validating it’s correctness. However, usually due to time limitations we either skip some tests or write poor quality ones. In such reality, while keeping in mind the amount of resources invested in unit testing development and maintenance, one must ask himself, given the available time, which code deserve testing the most? And from the existing tests, which tests are actually worth keeping and maintaining? See here
还没有人提到的一件事是,让所有开发人员承诺实际运行和更新任何现有的自动化测试。当您重新进行自动化测试并发现由于新的开发而出现故障时,会失去很多价值并使自动化测试非常痛苦。因为开发人员已经手动测试了代码,所以大多数测试不会指出错误,所以花在更新它们上的时间只是浪费。
说服怀疑者不要破坏其他人在单元测试上所做的工作,对于从测试中获得价值更为重要,而且可能更容易。
每次从存储库更新时,花费数小时更新由于新特性而损坏的测试既没有效率也没有乐趣。
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