我正致力于将单元测试集成到我所在团队的开发过程中,有一些人对此持怀疑态度。有什么好方法可以让团队中持怀疑态度的开发人员相信单元测试的价值?在我的具体情况下,我们将在添加功能或修复错误时添加单元测试。不幸的是,我们的代码库并不容易进行测试。
当前回答
单元测试适用于QA人员或你的经理,而不是你;所以绝对不值得。
您应该专注于编写正确的代码(不管这意味着什么),而不是测试用例。让其他人去担心吧。
其他回答
我曾多次尝试单元测试,我仍然相信,考虑到我的情况,这是值得的。
我开发网站,其中很多逻辑涉及在数据库中创建、检索或更新数据。当我为了单元测试的目的而尝试“模拟”数据库时,它变得非常混乱,似乎有点毫无意义。
当我围绕业务逻辑编写单元测试时,从长远来看它从未真正帮助过我。因为我主要独自从事项目工作,我倾向于直观地知道哪些代码区域可能会受到我所从事的工作的影响,并且我手动测试这些区域。我希望尽可能快地向客户交付解决方案,而单元测试通常看起来是浪费时间。我列出了手动测试,并亲自完成它们,并在执行过程中标记它们。
我可以看到,当一个开发团队在一个项目中工作并互相更新代码时,这可能是有益的,但即使这样,我认为如果开发人员具有高质量,良好的沟通和编写良好的代码通常就足够了。
@George Stocker“不幸的是,我们的代码库并不适合简单的测试。”每个人都同意单元测试有好处,但对于这个代码库来说,成本似乎很高。如果成本大于收益,那么他们为什么要对此充满热情呢?倾听你同事的意见;也许对他们来说,单元测试的痛苦比单元测试的价值更大。
具体地说,尽量尽快获得价值,而不是一些感觉良好的“xUnit是绿色的”价值,而是用户和维护者所重视的干净代码。也许您必须为一次迭代强制进行单元测试,然后讨论是否值得这样做。
[我有一个观点,我不能在上面看到]
“每个人都在进行单元测试,他们不一定意识到这一点——事实”
想想看,你写了一个函数来解析一个字符串并删除新的行字符。作为一个开发新手,你要么在命令行中通过Main()实现它来运行几个用例,要么用一个按钮组合一个可视化前端,将你的函数绑定到几个文本框和一个按钮上,然后看看会发生什么。
这就是单元测试——基本的和糟糕的组合在一起,但是你测试了一些情况下的代码段。
你写一些更复杂的东西。当您抛出一些用例(单元测试)并将其调试到代码中并进行跟踪时,它会抛出错误。你在浏览过程中查看这些值,并决定它们是对还是错。在某种程度上,这是单元测试。
这里的单元测试实际上是采用这种行为,将其形式化为结构化模式并保存,以便您可以轻松地重新运行这些测试。如果您编写了一个“适当的”单元测试用例而不是手动测试,那么它所花费的时间是相同的,或者随着您的经验的增加可能会更少,并且您可以一次又一次地重复它
单元测试的全部意义在于使测试变得简单。这是自动的。“make test”就完成了。如果您面临的问题之一是难以测试代码,那么这就是使用单元测试的最佳理由。
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
推荐文章
- 为什么Visual Studio 2015/2017/2019测试运行器没有发现我的xUnit v2测试
- 单元测试反模式目录
- 类未找到:IntelliJ中的空测试套件
- Mockito的argumentCaptor的例子
- 单元测试:日期时间。现在
- 为什么单元测试中的代码不能找到包资源?
- 从导入的模块中模拟函数
- 在单元测试中设置HttpContext.Current.Session
- 何时使用Mockito.verify()?
- 在PHP单元测试执行期间,如何在CLI中输出?
- 单元测试的一些常用命名约定是什么?
- 如何直接从测试驱动程序调用自定义的Django manage.py命令?
- 如何重置笑话模拟函数调用计数之前,每次测试
- 在Python Django中运行单元测试时,如何禁用日志记录?
- 在子目录中测试Golang