我正致力于将单元测试集成到我所在团队的开发过程中,有一些人对此持怀疑态度。有什么好方法可以让团队中持怀疑态度的开发人员相信单元测试的价值?在我的具体情况下,我们将在添加功能或修复错误时添加单元测试。不幸的是,我们的代码库并不容易进行测试。
当前回答
我在几年前发现了TDD,从那时起我就使用它编写了所有我喜欢的项目。我估计,TDD一个项目所花费的时间与牛仔式地组合一个项目所花费的时间大致相同,但我对最终产品的信心增加了,以至于我忍不住有一种成就感。
我还觉得它改进了我的设计风格(更面向界面,以防我需要一起模拟东西),而且,正如顶部的绿色帖子所写的,它有助于“编码便秘”:当你不知道接下来要写什么,或者你有一个令人生畏的任务摆在你面前时,你可以写小一点的。
最后,我发现到目前为止,TDD最有用的应用是在调试中,如果仅仅因为您已经开发了一个询问框架,那么您就可以用它来刺激项目以可重复的方式产生错误。
其他回答
你想说服谁?工程师还是经理?如果你试图说服你的工程师同事,我认为你最好的办法是迎合他们的愿望,让他们做出高质量的软件。有许多研究表明,它能发现漏洞,如果他们关心做好工作,这对他们来说就足够了。
如果您试图说服管理层,您将很可能不得不做一些成本/收益推理,说明未检测到的缺陷的成本大于编写测试的成本。一定要把不可转化的成本也包括在内,比如失去客户的信心等等。
单元测试非常值得最初的投资。自从几年前开始使用单元测试以来,我发现了一些真正的好处:
回归测试消除了恐惧 对代码进行更改(什么都没有 就像看到代码的温暖光芒 每次有变化,要么工作,要么爆发 了) 以下的可执行代码示例 其他团队成员(包括你自己) 6个月的时间…) 无情的重构——这是令人难以置信的回报,试试吧!
代码片段可以极大地帮助减少创建测试的开销。创建能够在几秒钟内创建类大纲和相关单元测试fixture的代码片段并不困难。
单元测试的好处之一是可预测性。
在单元测试之前,我可以非常准确地预测编写代码所需的时间,但无法预测调试所需的时间。
现在,因为我可以计划将要编写什么测试,所以我知道编码需要多长时间,并且在编码结束时,系统已经调试好了!这为开发过程带来了可预见性,消除了许多压力,但仍然保留了所有的乐趣!!
关于单元测试要记住的一件事是,它对开发人员来说是一种安慰。
相反,功能测试是针对用户的:无论何时添加功能测试,您都是在测试用户将看到的东西。当您添加单元测试时,您只是让开发人员的生活更轻松。在这方面有点奢侈。
当您必须在编写单元或功能测试之间做出选择时,请记住这种二分法。
Unit testing helps a lot in projects that are larger than any one developer can hold in their head. They allow you to run the unit test suite before checkin and discover if you broke something. This cuts down a lot on instances of having to sit and twiddle your thumbs while waiting for someone else to fix a bug they checked in, or going to the hassle of reverting their change so you can get some work done. It's also immensely valuable in refactoring, so you can be sure that the refactored code passes all the tests that the original code did.
推荐文章
- 为什么Visual Studio 2015/2017/2019测试运行器没有发现我的xUnit v2测试
- 单元测试反模式目录
- 类未找到:IntelliJ中的空测试套件
- Mockito的argumentCaptor的例子
- 单元测试:日期时间。现在
- 为什么单元测试中的代码不能找到包资源?
- 从导入的模块中模拟函数
- 在单元测试中设置HttpContext.Current.Session
- 何时使用Mockito.verify()?
- 在PHP单元测试执行期间,如何在CLI中输出?
- 单元测试的一些常用命名约定是什么?
- 如何直接从测试驱动程序调用自定义的Django manage.py命令?
- 如何重置笑话模拟函数调用计数之前,每次测试
- 在Python Django中运行单元测试时,如何禁用日志记录?
- 在子目录中测试Golang