我正致力于将单元测试集成到我所在团队的开发过程中,有一些人对此持怀疑态度。有什么好方法可以让团队中持怀疑态度的开发人员相信单元测试的价值?在我的具体情况下,我们将在添加功能或修复错误时添加单元测试。不幸的是,我们的代码库并不容易进行测试。
当前回答
使用单元测试套件,可以在保持其余功能不变的情况下对代码进行更改。这是一个很大的优势。当你完成新功能的编码时,你会使用单元测试套件和回归测试套件吗?
其他回答
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
如果你正在使用NUnit,一个简单而有效的演示就是在他们面前运行NUnit自己的测试套件。看到一个真正的测试套件对代码库进行测试,胜过千言万语……
单元测试非常值得最初的投资。自从几年前开始使用单元测试以来,我发现了一些真正的好处:
回归测试消除了恐惧 对代码进行更改(什么都没有 就像看到代码的温暖光芒 每次有变化,要么工作,要么爆发 了) 以下的可执行代码示例 其他团队成员(包括你自己) 6个月的时间…) 无情的重构——这是令人难以置信的回报,试试吧!
代码片段可以极大地帮助减少创建测试的开销。创建能够在几秒钟内创建类大纲和相关单元测试fixture的代码片段并不困难。
多年来,我一直试图说服人们,他们需要为自己的代码编写单元测试。无论他们是先编写测试(如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.
改变不会在一夜之间发生,但只要有一点耐心,你就可能实现你的目标。
测试驱动开发中经常被忽略的一个主要部分是可测试代码的编写。乍一看,这似乎是一种妥协,但您会发现可测试代码最终也是模块化的、可维护的和可读的。 如果你仍然需要说服别人,这是一个关于单元测试优点的简单演示。
推荐文章
- 如何直接从测试驱动程序调用自定义的Django manage.py命令?
- 如何重置笑话模拟函数调用计数之前,每次测试
- 在Python Django中运行单元测试时,如何禁用日志记录?
- 在子目录中测试Golang
- 如何比较单元测试中的列表
- 在Xcode单元测试中使用@可测试时“没有这样的模块”
- 更改mocha的默认超时时间
- 如何单元测试Arduino代码?
- 单元测试无效方法?
- 在单元测试中模拟HttpClient
- 为什么visual studio 2012找不到我的测试?
- 无法找到testhost.dll。请发布测试项目并重试
- 我如何“休眠”Dart程序
- 使用Mockito的泛型“any()”方法
- 在Visual Studio 2017中未发现单元测试