我正致力于将单元测试集成到我所在团队的开发过程中,有一些人对此持怀疑态度。有什么好方法可以让团队中持怀疑态度的开发人员相信单元测试的价值?在我的具体情况下,我们将在添加功能或修复错误时添加单元测试。不幸的是,我们的代码库并不容易进行测试。
当前回答
多年来,我一直试图说服人们,他们需要为自己的代码编写单元测试。无论他们是先编写测试(如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.
改变不会在一夜之间发生,但只要有一点耐心,你就可能实现你的目标。
其他回答
多年来,我一直试图说服人们,他们需要为自己的代码编写单元测试。无论他们是先编写测试(如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.
改变不会在一夜之间发生,但只要有一点耐心,你就可能实现你的目标。
关于单元测试要记住的一件事是,它对开发人员来说是一种安慰。
相反,功能测试是针对用户的:无论何时添加功能测试,您都是在测试用户将看到的东西。当您添加单元测试时,您只是让开发人员的生活更轻松。在这方面有点奢侈。
当您必须在编写单元或功能测试之间做出选择时,请记住这种二分法。
@George Stocker“不幸的是,我们的代码库并不适合简单的测试。”每个人都同意单元测试有好处,但对于这个代码库来说,成本似乎很高。如果成本大于收益,那么他们为什么要对此充满热情呢?倾听你同事的意见;也许对他们来说,单元测试的痛苦比单元测试的价值更大。
具体地说,尽量尽快获得价值,而不是一些感觉良好的“xUnit是绿色的”价值,而是用户和维护者所重视的干净代码。也许您必须为一次迭代强制进行单元测试,然后讨论是否值得这样做。
当你说“我们的代码库不适合简单的测试”时,这是代码气味的第一个迹象。编写单元测试意味着您通常以不同的方式编写代码,以使代码更具可测试性。在我看来,这是一件好事,因为多年来我在编写代码时看到我必须为其编写测试,这迫使我提出更好的设计。
测试驱动开发中经常被忽略的一个主要部分是可测试代码的编写。乍一看,这似乎是一种妥协,但您会发现可测试代码最终也是模块化的、可维护的和可读的。 如果你仍然需要说服别人,这是一个关于单元测试优点的简单演示。
推荐文章
- 如何直接从测试驱动程序调用自定义的Django manage.py命令?
- 如何重置笑话模拟函数调用计数之前,每次测试
- 在Python Django中运行单元测试时,如何禁用日志记录?
- 在子目录中测试Golang
- 如何比较单元测试中的列表
- 在Xcode单元测试中使用@可测试时“没有这样的模块”
- 更改mocha的默认超时时间
- 如何单元测试Arduino代码?
- 单元测试无效方法?
- 在单元测试中模拟HttpClient
- 为什么visual studio 2012找不到我的测试?
- 无法找到testhost.dll。请发布测试项目并重试
- 我如何“休眠”Dart程序
- 使用Mockito的泛型“any()”方法
- 在Visual Studio 2017中未发现单元测试