我正致力于将单元测试集成到我所在团队的开发过程中,有一些人对此持怀疑态度。有什么好方法可以让团队中持怀疑态度的开发人员相信单元测试的价值?在我的具体情况下,我们将在添加功能或修复错误时添加单元测试。不幸的是,我们的代码库并不容易进行测试。
当前回答
如果你正在使用NUnit,一个简单而有效的演示就是在他们面前运行NUnit自己的测试套件。看到一个真正的测试套件对代码库进行测试,胜过千言万语……
其他回答
偶尔,我自己或我的同事会花几个小时来研究一个不太明显的错误,一旦发现了错误的原因,90%的情况下代码都没有经过单元测试。单元测试并不存在,因为开发人员为了节省时间而偷工减料,但随后却失去了这一点和更多的调试。
花少量的时间来编写单元测试可以节省未来调试的时间。
多年来,我一直试图说服人们,他们需要为自己的代码编写单元测试。无论他们是先编写测试(如TDD)还是在编写功能之后,我总是试图向他们解释对代码进行单元测试的所有好处。几乎没有人反对我。你不能否认一些显而易见的事情,任何聪明的人都会看到单元测试和TDD的好处。
单元测试的问题在于它需要行为上的改变,而要改变人们的行为是非常困难的。用语言,你会让很多人同意你的观点,但你不会看到他们做事的方式有太多变化。
你必须通过行动来说服人们。你的个人成功会比你的争论吸引更多的人。如果他们看到你不只是在谈论单元测试或TDD,而是在做你鼓吹的事情,而且你是成功的,人们就会试图模仿你。
You should also take on a lead role because no one writes unit test right the first time, so you may need to coach them on how to do it, show them the way, and the tools available to them. Help them while they write their first tests, review the tests they write on their own, and show them the tricks, idioms and patterns you've learned through your own experiences. After a while, they will start seeing the benefits on their own, and they will change their behavior to incorporate unit tests or TDD into their toolbox.
改变不会在一夜之间发生,但只要有一点耐心,你就可能实现你的目标。
单元测试非常值得最初的投资。自从几年前开始使用单元测试以来,我发现了一些真正的好处:
回归测试消除了恐惧 对代码进行更改(什么都没有 就像看到代码的温暖光芒 每次有变化,要么工作,要么爆发 了) 以下的可执行代码示例 其他团队成员(包括你自己) 6个月的时间…) 无情的重构——这是令人难以置信的回报,试试吧!
代码片段可以极大地帮助减少创建测试的开销。创建能够在几秒钟内创建类大纲和相关单元测试fixture的代码片段并不困难。
简而言之——是的。它们值得你付出每一分努力……在某种程度上。在一天结束的时候,测试仍然是代码,并且很像典型的代码增长,您的测试最终将需要重构,以便可维护和可持续。有一大堆的陷阱!当涉及到单元测试时,但是没有什么,我的意思是没有什么比丰富的单元测试集更能让开发人员更自信地进行更改了。
I'm working on a project right now.... it's somewhat TDD, and we have the majority of our business rules encapuslated as tests... we have about 500 or so unit tests right now. This past iteration I had to revamp our datasource and how our desktop application interfaces with that datasource. Took me a couple days, the whole time I just kept running unit tests to see what I broke and fixed it. Make a change; Build and run your tests; fix what you broke. Wash, Rinse, Repeat as necessary. What would have traditionally taken days of QA and boat loads of stress was instead a short and enjoyable experience.
提前准备,一点点额外的努力,当你不得不开始摆弄核心特性/功能时,它会给你带来十倍的回报。
我买了这本书——它是xUnit测试知识的圣经——它可能是我书架上被引用最多的书之一,我每天都在查阅它:链接文本
测试驱动开发中经常被忽略的一个主要部分是可测试代码的编写。乍一看,这似乎是一种妥协,但您会发现可测试代码最终也是模块化的、可维护的和可读的。 如果你仍然需要说服别人,这是一个关于单元测试优点的简单演示。
推荐文章
- 为什么Visual Studio 2015/2017/2019测试运行器没有发现我的xUnit v2测试
- 单元测试反模式目录
- 类未找到:IntelliJ中的空测试套件
- Mockito的argumentCaptor的例子
- 单元测试:日期时间。现在
- 为什么单元测试中的代码不能找到包资源?
- 从导入的模块中模拟函数
- 在单元测试中设置HttpContext.Current.Session
- 何时使用Mockito.verify()?
- 在PHP单元测试执行期间,如何在CLI中输出?
- 单元测试的一些常用命名约定是什么?
- 如何直接从测试驱动程序调用自定义的Django manage.py命令?
- 如何重置笑话模拟函数调用计数之前,每次测试
- 在Python Django中运行单元测试时,如何禁用日志记录?
- 在子目录中测试Golang