我正致力于将单元测试集成到我所在团队的开发过程中,有一些人对此持怀疑态度。有什么好方法可以让团队中持怀疑态度的开发人员相信单元测试的价值?在我的具体情况下,我们将在添加功能或修复错误时添加单元测试。不幸的是,我们的代码库并不容易进行测试。
当前回答
我同意与大多数人相反的观点: 不编写单元测试是可以的 特别是重原型的编程(例如AI)很难与单元测试相结合。
其他回答
单元测试可以帮助您以更少的错误发布软件,同时降低总体开发成本。您可以点击链接阅读更多关于单元测试的好处
如果你正在使用NUnit,一个简单而有效的演示就是在他们面前运行NUnit自己的测试套件。看到一个真正的测试套件对代码库进行测试,胜过千言万语……
我是一名维护工程师,负责一个文档记录不佳、糟糕而庞大的代码库。我希望编写代码的人已经为它编写了单元测试。 每次我进行更改和更新产品代码时,我都担心自己可能会因为没有考虑某些条件而引入错误。 如果他们编写测试,那么对代码库的更改就会更容易、更快。(与此同时,代码库将处于更好的状态)..
我认为,在编写api或框架时,单元测试非常有用,因为这些api或框架必须持续多年,并由原始编码器以外的人使用/修改/发展。
[我有一个观点,我不能在上面看到]
“每个人都在进行单元测试,他们不一定意识到这一点——事实”
想想看,你写了一个函数来解析一个字符串并删除新的行字符。作为一个开发新手,你要么在命令行中通过Main()实现它来运行几个用例,要么用一个按钮组合一个可视化前端,将你的函数绑定到几个文本框和一个按钮上,然后看看会发生什么。
这就是单元测试——基本的和糟糕的组合在一起,但是你测试了一些情况下的代码段。
你写一些更复杂的东西。当您抛出一些用例(单元测试)并将其调试到代码中并进行跟踪时,它会抛出错误。你在浏览过程中查看这些值,并决定它们是对还是错。在某种程度上,这是单元测试。
这里的单元测试实际上是采用这种行为,将其形式化为结构化模式并保存,以便您可以轻松地重新运行这些测试。如果您编写了一个“适当的”单元测试用例而不是手动测试,那么它所花费的时间是相同的,或者随着您的经验的增加可能会更少,并且您可以一次又一次地重复它
测试驱动开发中经常被忽略的一个主要部分是可测试代码的编写。乍一看,这似乎是一种妥协,但您会发现可测试代码最终也是模块化的、可维护的和可读的。 如果你仍然需要说服别人,这是一个关于单元测试优点的简单演示。
推荐文章
- 如何直接从测试驱动程序调用自定义的Django manage.py命令?
- 如何重置笑话模拟函数调用计数之前,每次测试
- 在Python Django中运行单元测试时,如何禁用日志记录?
- 在子目录中测试Golang
- 如何比较单元测试中的列表
- 在Xcode单元测试中使用@可测试时“没有这样的模块”
- 更改mocha的默认超时时间
- 如何单元测试Arduino代码?
- 单元测试无效方法?
- 在单元测试中模拟HttpClient
- 为什么visual studio 2012找不到我的测试?
- 无法找到testhost.dll。请发布测试项目并重试
- 我如何“休眠”Dart程序
- 使用Mockito的泛型“any()”方法
- 在Visual Studio 2017中未发现单元测试